r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Red] Red language group

Kaj
23-Jun-2011
[2448x2]
*** Compilation Error: more than one expression found in parentheses
That seriously limits the usefulness of ANY and ALL
Dockimbel
23-Jun-2011
[2450]
How does that limit ANY and ALL?
Kaj
23-Jun-2011
[2451x2]
unless all [
	(
		message: receive socket 0
		as-logic message
	)(

  prin "Received request: "  print as-c-string message-data message
		end-message message
	)(
		;wait 1
		send socket  as [byte-ptr!] reply  1 + length? text  0
	)
][
	print zmq-form-error system-error
]
That's how I always use them
Dockimbel
23-Jun-2011
[2453]
You can't do such construction in Red/System.
Kaj
23-Jun-2011
[2454]
Right, that's what I mean
Dockimbel
23-Jun-2011
[2455x2]
Assignments can't be used inside an expression, nor can functions 
that don't have a return value.
Btw, allowed expressions are now documented: http://static.red-lang.org/red-system-specs.html#section-5.1
Kaj
23-Jun-2011
[2457]
Any plans to support this?
Dockimbel
23-Jun-2011
[2458]
Red/System is not meant to be a REBOL replacement, you will need 
to wait for Red.
Kaj
23-Jun-2011
[2459]
But isn't that the point? :-) There are no replacements for REBOL 
at all, and we can't wait any longer
Dockimbel
23-Jun-2011
[2460]
Red/System cannot be a REBOL replacement, it doesn't live at the 
same level of abstraction.
Kaj
23-Jun-2011
[2461]
I know, but this one is very doable. I guess it would be a nice project 
for Brian
Dockimbel
23-Jun-2011
[2462x2]
I could remove the compiler check, so that your code "might" compile, 
but that opens a hole for several others issues.
That compiler check has been added to solve the issues reported here: 
https://github.com/dockimbel/Red/issues/93
Steeve
23-Jun-2011
[2464]
assignements don't return a value in Red ? 
It should be doable without pain.
Dockimbel
23-Jun-2011
[2465x2]
Currently, no.
There is a possible evolution documented in the specification for 
that, allowing also multi-assignments as a side-effect.
Steeve
23-Jun-2011
[2467]
a cool side effect
Dockimbel
23-Jun-2011
[2468]
Yeah :-)
Kaj
23-Jun-2011
[2469]
It sort of pulls the base out from under my efforts to wrap all external 
functions to return logic!
Dockimbel
23-Jun-2011
[2470]
You could just write wrapper functions.
Kaj
23-Jun-2011
[2471]
I did, but after that, I was expecting to plug them into ANY and 
ALL :-)
Dockimbel
23-Jun-2011
[2472x2]
or use logic! as return value in the imported function definition?
(as return type)
Kaj
23-Jun-2011
[2474]
No, we discussed that
Dockimbel
23-Jun-2011
[2475]
I don't remember the conclusion?
Kaj
23-Jun-2011
[2476]
Only possible when the #import returns 0 and 1 exactly
Dockimbel
23-Jun-2011
[2477]
Ah right!
Kaj
23-Jun-2011
[2478]
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
Dockimbel
23-Jun-2011
[2479]
I still don't get why you can't solve that with wrapper functions?
Kaj
23-Jun-2011
[2480]
How do you mean? Writing three extra functions just for that one 
ALL expression?
Dockimbel
23-Jun-2011
[2481]
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!.
Kaj
23-Jun-2011
[2482]
I did. NULL also needs to be cast to logic
Dockimbel
23-Jun-2011
[2483]
Also, those wrappers could handle the low-level ZMQ errors, so that 
the user don't have to do it.
Kaj
23-Jun-2011
[2484]
No, because there is no standard for error reporting, like in REBOL. 
You have to do error trapping the C way
Dockimbel
23-Jun-2011
[2485]
I just mean findind a way to catch those 0 values transparently.
Kaj
23-Jun-2011
[2486x2]
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
Dockimbel
23-Jun-2011
[2488]
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.
Kaj
23-Jun-2011
[2489]
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
Dockimbel
23-Jun-2011
[2490x2]
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.
Kaj
23-Jun-2011
[2492x2]
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
Dockimbel
23-Jun-2011
[2494x2]
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 
:)
Kaj
23-Jun-2011
[2496]
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
Dockimbel
23-Jun-2011
[2497]
My point was: don't return a logic! statut from functions like RECEIVE, 
rather set a flag and check it after RECEIVE call.