World: r3wp
[Red] Red language group
| older newer | first last |
| BrianH 29-Dec-2011 [4121] | IF, UNLESS, EITHER, CASE and SWITCH all make sense to compile in a compiled language because they all translate to branches and/or index lookups in the generated code, and optimizing that would need some decent compiler support. If anything, CASE is the most general (the others can all be implemented with CASE), and would benefit the most from optimization. |
| Pekr 29-Dec-2011 [4122] | what is make-float-auto-test.r? Do we have floats supported or so? :-) |
| Kaj 29-Dec-2011 [4123] | Nice catch :-) |
| Pekr 29-Dec-2011 [4124x2] | I think we don't, so maybe just a preparation for what is about to come one day :-) IIRC Doc was investigating, what would it take to get floats supported by RED/System :-) |
re Documentation - Content is missing 13.3.7 CASE | |
| Kaj 29-Dec-2011 [4126] | See above |
| Pekr 29-Dec-2011 [4127] | Kaj - I mean - CASE is described, but it is not part of the basic points ... |
| Dockimbel 29-Dec-2011 [4128x2] | Pekr: the ... just indicates that the <condition> [<body>] pattern can be repeated. |
make-float-auto-test.r: just some preliminary tests from Peter, nothing has been implemented yet wrt float. | |
| Kaj 29-Dec-2011 [4130] | Isn't the TOC autogenerated by MakeDoc? |
| Dockimbel 29-Dec-2011 [4131x4] | It is. |
I don't see missing content in online doc?? | |
Mezz in Red: yes, they will be compiled. | |
CASE in Red/System and CASE in Red are two different functions. The Red version may or may not rely on the Red/System one. | |
| Pekr 29-Dec-2011 [4135] | my mistake. TOC does not containt full details. CASE is 13.3.7, but TOC uses two levels - 13.3, so it is OK ... |
| Dockimbel 29-Dec-2011 [4136] | Right, two levels is already quite long, not sure I should extend it more? |
| Kaj 29-Dec-2011 [4137] | I do agree that it is a bit hard to find specific things in the current manual |
| Dockimbel 29-Dec-2011 [4138x5] | CASE/all: could be added to Red/System (would be called case-all), but as I'm personally not a great user of CASE/all, I'll wait for other users to ask for it. ;-) |
Specification: I agree that find the native function is not handy, I could remove the "API Reference" level to make it easier to find from TOC. | |
find => finding | |
BTW, the "manual" is supposed to be a (more or less formal) specification of the language, but as I didn't have time to write a separate user manual, it now tends to serve for both uses. | |
New handier (I hope) chapters layout: http://static.red-lang.org/red-system-specs.html | |
| Kaj 29-Dec-2011 [4143] | Looks good |
| Henrik 29-Dec-2011 [4144x2] | What is returned, when no case passes? |
I mean, whether that is necessary to have in the specs. | |
| Dockimbel 29-Dec-2011 [4146] | In such case, result is undefined. If you need a return value, it's up to you to provide a "catch all" ending rule that never fail. |
| BrianH 29-Dec-2011 [4147] | Out of curiosity, Doc, not criticism, why did you pick the 3-clause BSD license instead of the 2-clause BSD? |
| Dockimbel 30-Dec-2011 [4148x2] | Just because it looked good to me when I had to pick one. But since then, Andreas made me realize that it can be problematic for derivated works because of the "prior written permission" part. That is why the current Red runtime source code is licensed under the Boost License. I think I'll just re-license the whole source base under BSD 2-clause when I'll find some time for that. |
derivated => derivative (hard remembering this one) | |
| Andreas 30-Dec-2011 [4150x3] | The reason for using the Boost License for the runtime was clause two: "Redistributions in binary form must reproduce the above copyright notice, ..." . |
A Red/System-produced binary linked with the Red/System runtime arguably is a redistribution of the Red/System runtime in binary form. | |
The Boost Software License is even more permissive in this regard, and should therefore make sure that Red/System-produced binaries can be distributed without any restriction. | |
| Dockimbel 30-Dec-2011 [4153] | Forgot about that, right! So not even the 2-clause BSD is permissive enough? |
| Andreas 30-Dec-2011 [4154] | Nope, I'd suggest sticking with the BSL for the runtime. |
| BrianH 30-Dec-2011 [4155x2] | The heck with it, go with the WTFPL :) |
Andreas, you forgot the "in the documentation and/or other materials provided with the distribution" - it's iffy as to whether you need to provide them in the binary itself. Still, the BSL looks good. I should consider it for R2/Forward and my R3 mezzanine work, since the MIT license has the same restriction as the second clause of BSD-2. | |
| Dockimbel 30-Dec-2011 [4157x4] | WTFPL looks good. ;-) |
SWITCH native implemented in Red/System, here is an example of supported features: a: 5 ret: switch a [ 0 [print "0" 0] 1 #"^E" [print "1" 1] 2 6 [print "2" 2] 3 [print "3" 3] default [print "no match" -1] ] print [lf ret lf] | |
* Mutiple values allowed (even mixing integer! and byte!) * Returns last value * Optional default clause | |
Also the SWITCH argument can be any valid Red/System expression. | |
| BrianH 30-Dec-2011 [4161x4] | Are the clauses you are matching (minimally) evaluated, or unevaluated like in REBOL? Would the default clause conflict with a: 'default ? |
Gabriele used this model instead for Topaz: ret: switch a [ 0 [print "0" 0] 1 #"^E" [print "1" 1] 2 6 [print "2" 2] 3 [print "3" 3] ] [ print "no match" -1 ] | |
That's a mandatory default clause, which can be empty. | |
Up to you of course :) | |
| Dockimbel 30-Dec-2011 [4165] | Unevaluated, but only integer! and byte! literals are allowed. [ a: 'default ] No word!, this is Red/System, not Red. :) Anywhere adding words as symbols only in Red/System might not be a bad idea in future. |
| BrianH 30-Dec-2011 [4166x2] | Characters are bytes in Red/System, right, I forgot. |
What does SWITCH return when you don't have a default clause and none of the choices match? None? Some undefined value? Trigger an error? | |
| Dockimbel 30-Dec-2011 [4168x3] | Topaz's SWITCH: that's an alternative syntax that is closer to the REBOL's one. I think that most users will hit the "I forgot to put the empty [ ]" issue at least once, so I'm rather for the "optional part should be optional" approach. |
Same as for CASE: undefined value. | |
Suggestions for improving that are welcome (both for CASE and SWITCH), as long as they don't require a lot of additional coding. | |
| older newer | first last |