World: r3wp
[Red] Red language group
older newer | first last |
Kaj 23-Jun-2011 [2447x3] | I'm getting this: |
*** 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 |
older newer | first last |