[data type conversion] question

== "9/5*100+32"

** Syntax Error: Invalid date -- 9/5 ** Near: (line 1) to-string [9/5 * 100 + 32]

Finally my question is : Can REBOL be told to not evaluate each element of the block contents I submit him when calling my function but simply replaces the end delimiters [ ] for the appropriately ones " " ? I would simply find more natural to let the user enter the conventional brackets [ ] delimiters around the maths expression to evaluate than remember to use the quotes " ". May be I could even afford for letting the operator to use anyone of them if he desires to do so. In fact when using the quotes as delimiters I can afford the user to write his expressions without having to insert spaces everywhere since I control the expression parsing myself and this is what motivated me in the first case to use the [ ] delimiters also. Don't forget that this is not to replace the conventional expression parser as found in REBOL but to help younger people to start learning without having to bother themselves with not standard maths expressions. Thanks, Gerard

the only way this would work is if you put "" around the 9/5

its not really evaluating the block, but its trying to create the data in memory and 9/5 is seen to be a date... (but badly formed) just doing:

will give the same error. since this is a syntax error, then 9/5 is the same kind of error as if you where trying to create a string with no end bracket, or any other value...

will always fail no matter how deep you nest it in blocks the real thing is ... do you really need to put things in the block form... in this case, I'm pretty sure the answer is no. HTH! -MAx

You're right but it was only a question - I thought that may be REBOL would let the programmer escape the normal way of doing things when necessary and even specify other characters ("") to use as a replacement for the normal REBOL block delimiters [ ] for enclosing the full expression to parse. Something like in the following: input-expr: [9/5 * 100 + 32] parse/no-block-eval input-expr rules or parse/block-to-string input-expr rules or any other suggestion ... in fact In my view it would a bit different from the current parse/all refinement where we can specify other delimiters for the splitting of tokens when scanning the input expression. Here it looks more like a simple cosmetic addition but it would have the effect of being able to specify the input expression from a REBOL block (which is so natural) instead of using a string. The first natural way I could see it is to ask PARSE to not take into account its normal eval mode so it could nom more complain when encountering ill-formed datatypes. The simplest way to let PARSE do this would be to ask him to internally replace the ending [] by "" and continue its normal life using all its current knowledge. No more frills. Even simpler would be to let him automatically detect the presence of [] instead of "" but as I suppose some scripts already take the normal REBOL way of doing things into account and use it in their own way - it would not be very safe to do this, be it only for compatibility reason. After all this is simply a cosmetic suggestion to let PARSE be itself more REBOLish in some way, that is even for just being able to cope with this kind of expression - at least this is my own view of the subject and I know PARSE can be modified relatively easily by Carl it this is really needed. It's also suggested here more for discussion of the global impacts on adding such a mechanism for PARSE and may be suggest the better way to handle this if PARSE had to be changed to handle this situation in a future release. Consider this to be on my personal wish list and asking others their POV on the question! Regards, Gerard

datatypes,

For your interest, have a look at item 59 and 60 on this page: http://www.rebol.net/projects/view1.3/chat47.html Regards, Brett.

Brett replied :