Good points Ladislav. For your original question, the help for CASE says that what follows a condition is only evaluated if the condition is true, which seems OK to me.
Ladislav
Hi, Gregg. Unfortunately, "only evaluated if the condition is true" does not specifiy the behaviour as precisely as one may think. The examples below demonstrate the problem.
blk: [1 +] case [ true append blk 2 ]
versus
blk: [1 +] case [ false append blk 2 ]
, or similarblk: [1 +] case [ true append blk 2 ] blk: [1 +] case [ true append blk 2 ]
sorry, copy and paste problem
ignore the text following the comma, please
Gregg
So what is the actual behavior? That is, what does get evaluated and what doesn't? Clearly stating how each is intended to work seems to be the first step. For example, should CASE enforce that values following conditions must be block types?
I can see the problem, with free-ranging evaluation, so constructs like your latest example seem like a bad idea in any case.
Ladislav
Well, the first example (preceding the "versus" word) yields 3 in Rebol 3, as well as in Rebol 2, and I dare to guess that it was intended.
Ladislav
The behaviour looks as inspired by IF. However, the behaviour of the second example (following the "versus" word) does not look reasonable, and I dare to say that it is a design (or implementation) flaw.
Gregg
So, in the latter case 'blk should be [1 + 2] and CASE should return none.
What was the reason for allowing non-block values for the cases, for both IF and CASE? Your examples tell me that it can be abused and hurt readability. Are there scenarios where it helps?
GiuseppeC
MARCO: How should I use the EAN 128 font in REBOL 3 ?
GiuseppeC
What is blocking me to fully integrate REBOL in a company: ODBC driver with some errors No BARCODE support No way to print a label using it No way to rapresent a sheet of data using a report and print it or send it as PDF Maybe since the last time I have used REBOL 3 things have changed. Have you some solution, even integrating rebol with other technologies/libraries ?
Henrik
Regarding printing, there was some fairly functional and fast postscript output for REBOL2, which I used a lot between 2007 and 2013. Then I used adobe's virtual postscript printer, which then generates a file for the printer. I think also it can generate PDFs. It's also possible to generate postscript directly for the printer, but then the output becomes printer dependent and much harder to work with.
I had written a dialect on top of the postscript dialect, so I could output VID layouts as postscript.
Maybe there should be some work done on porting the postscript dialect to R3, and then you can use the above to support the rest.
GiuseppeC
Henrik, I don't have the skill for such high profile modification. I could propose a bounty for it. I don't want also do any work on REBOL2 because we must concentrate all of our forces on R3 I (we) need the following: Printing on any size of paper (from A4 to rectangular labels) arranged with images and barcodes. This would unblock a whole new opprtunities for REBOL3 to be used in companies.
Henrik
I believe it can be done. However I wish also it to make sense in a larger printing tool-chain, from authoring to printing.
GiuseppeC
Next week I'll propose a bounty.
Henrik
I hope there will be someone available to do it. :-)
PeterWood
In Rebol2, this works:
>> do load make block! "a: 1 print a" 1
But in Rebol3 , it doesn'tt: >> do load make block! "a: 1 print a" ** Script error: -apply- does not allow set-word! for its source argument ** Where: apply map-each case load ** Near: apply :load [:item header all type ftype]
Does anybody know why this change of behaviour was made?
WiseGenius
The problem is this part: >> load [a: 1 print a] ** Script error: -apply- does not allow set-word! for its source argument ** Where: apply map-each case load ** Near: apply :load [:item header all type ftype]
I'm still a noob in Rebol, but my guess is that using `load` on a block in Rebol 2 returns the original block, but in Rebol 3 it returns a block with `load` applied to each value in the block.
I'll try again without the HTTP link: The reason that I ask is that Ladislav's explanation of the Rebol interpreter in Wiki iBooks s based on it working. Perhaps his explanation only applies to Rebol 2.
Endo
In the page you sent, Ladislav says: "if the do function evaluates an error! datatype value and the value isn't used as an argument to a function accepting error values, the interpreter causes the error. In my opinion, this exception is unnecessary and can be painlessly avoided in the future versions of the interpreter."
Is this changed already? >> f: func [e [error!]] [true] >> f x == true