World: r3wp

That compiler check has been added to solve the issues reported here: 
https://github.com/dockimbel/Red/issues/93

assignements don't return a value in Red ? 
It should be doable without pain.

Currently, no.

There is a possible evolution documented in the specification for 
that, allowing also multi-assignments as a side-effect.

a cool side effect

Yeah :-)

It sort of pulls the base out from under my efforts to wrap all external 
functions to return logic!

You could just write wrapper functions.

I did, but after that, I was expecting to plug them into ANY and 
ALL :-)

or use logic! as return value in the imported function definition?

(as return type)

No, we discussed that

I don't remember the conclusion?

Only possible when the #import returns 0 and 1 exactly

Ah right!

Anyway, returning 0 for succes is unnatural for humans, but very 
natural for C. If there is no REBOL like way to process the reverse 
logic! return, the C way becomes more attractive, and the code shifts 
towards C instead of REBOL

I still don't get why you can't solve that with wrapper functions?

How do you mean? Writing three extra functions just for that one 
ALL expression?

I mean writing wrappers for low-level ZMQ imported functions, so 
that they return consistent values. For example, RECEIVE should return 
a message! or null, but not a 0 that needs to be casted to logic!.

I did. NULL also needs to be cast to logic

Also, those wrappers could handle the low-level ZMQ errors, so that 
the user don't have to do it.

No, because there is no standard for error reporting, like in REBOL. 
You have to do error trapping the C way

I just mean findind a way to catch those 0 values transparently.

There is no 0, only NULL, and this is my attempt at implementing 
the error catching, transparent or not

I know you don't want more changes before implementing Red, and that's 
fair enough, but this is something we'll need eventually

Here a code example of how you could solve that:
	msg: receive ....
  	if zmq-error? [...process error...]


zmq-error? could just check a flag set by last zmq low-level calls.

Such constructs would make the binding a lot more high level and 
would require a lot more code. I'm trying to keep complexity down 
for simplicity and performance

calls => call

The added code won't make any significant overhead in performances 
for a network communication library, the slow parts are the network 
exchanges.

What bothers me most is the added complexity that doesn't really 
solve the problem. Error handling is often something that needs to 
be done locally, because that's where the knowledge is to handle 
the problem most gracefully

We don't have goto and longjumps, either, so there's little leeway 
for implementing a transparent error trapping framework

Btw, your code snippet could be rewritten as:

message: receive socket 0
unless all [
	as-logic message
	end-message message
	;wait 1
	send socket  as [byte-ptr!] reply  1 + length? text  0
][

 prin "Received request: "  print as-c-string message-data message
	print zmq-form-error system-error
]

Huh, I guess I have been too aggressive with the prin "..." line 
:)

If you want the function to return a logic! status and a result to 
be able to handle it locally, the result needs to fetched through 
a pointer, which also raises complexity. We can't handle addresses 
very well yet, either, because get-words only work for native functions

My point was: don't return a logic! statut from functions like RECEIVE, 
rather set a flag and check it after RECEIVE call.

statut => status

RECEIVE doesn't return logic?

That rewrite doesn't work. It mixes up successful and unsuccessful 
receiving

Yeah right, I was confused by your will to return a logic!.

I'm flexible. :-) Not everything returns logic, only the cases that 
can

I'll just rewrite it in EITHERs for now. I'm just noting that it 
can be made very nicely REBOL like to distinguish Red/System from 
C

By the way, 0MQ is not a network communication library per se. It 
can do messaging equally well between processes and even threads, 
so wrapper performance is significant

x: does []
either true [x] [x]

*** Compiler Internal Error: Script Error : equal-types? expected 
type1 argument of type: word
*** Where: comp-either 
*** Near:  [last-type: either equal-types? t-true t-false]

Regression from a recent change, you should get a compilation error 
saying that x is missing a return value.

In this case, I don't need EITHER to return a value

The crash is on the EITHER not on the DOES

Ok, so sounds like a check that shouldn't happen in such case.

Could you post this error (and future others) to github's tracker 
please? It is easier for me to manage them there.

I won't like loosing the comfort of AltME, but I'll try