Hi gerard,
actually,
the problem with:
input-expr: [9/5 * 100 + 32]
parse/no-block-eval input-expr rules
is not in the parse, its when you try to create the block in the first place.
its trying to allocate memory for each item in itself, but when in encounters
the 9/5 it bails out.
I understand your point about parse.
I think that to say rebol truely supports dialects, we should be able to do
things like:
blk: make block! [9/5 * 100 + 32]
and rebol should be able to leave it as is in a form or another.
but because we cannot create our own datatypes, then there is no point in it,
because the parser will NEVER be able to convert the 9/5 into an actual value
within rebol.
excuse me for sounding critical here, but rebol should let us create datatypes,
for dialects in the least. I can't see why dialects should have to follow
rebol's syntax.... this is true for operator too.
isn't it the point of a dialect to be able to give a part of code its own
meaning... and The way I see it, part of that meaning lies in how the data
itself is represented.
using the example above, I could clearly see a dialect which accepts fractions
as a way to create decimal or integer values... maybe rebol could transform the
parts of a block it could not evaluate into a special string type. this could
be dialect! type.
Then we could parse it as a string series and create values out of it through a
dialect. This would allow us to create pseudo datatypes, by using normally
invalid rebol code.
just my two cents on the issue!
-MAx
----- Original Message -----
From: "Gerard Cote" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 28, 2004 4:21 PM
Subject: [REBOL] Re: [data type conversion] question
>
> Hi Maxim,
>
> Thanks for your prompt answer !
>
> > 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.
>
> 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
>
>
> --
> To unsubscribe from this list, just send an email to
> [EMAIL PROTECTED] with unsubscribe as the subject.
>
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
