[data type conversion] question
[1/9] from: gerardcote:sympatico:ca at: 26-Mar-2004 14:10
Hi all,
While continuing my work about forthcoming REBOL tutorial for youngsters, I planned some
helper function to help them express maths
expression using the normal infix and precedence rules - like most calculators do. May
be this will not even be included at all with
the tutorial but it was a good excuse for me to investigate how I could learn more about
the parse word to create some translation
tool.
This worked for the most part and I went into some real knowledge that I will share here
soon and post the final products to the
official library to accompany other scripts found there about calculators and related
engines.
The only real question left came to me when I tried to call my calc with some real but
not well formed expressions using a block
instead of a string like in the following :
>> to-string [9 / 5 * 100 + 32] ; Here is the well formed version of
my test expression
== "9/5*100+32"
>> to-string [9/5 * 100 + 32] ; Here is the ill-formed version of
the same expression
** 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
[2/9] from: maximo:meteorstudios at: 26-Mar-2004 14:54
> >> to-string [9/5 * 100 + 32] ; Here is
> the ill-formed version of the same expression
<<quoted lines omitted: 6>>
> but simply replaces the end delimiters [ ] for the
> appropriately ones " " ?
the only way this would work is if you put "" around the 9/5
>> to-string ["9/5" * 100 + 32]
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:
>> [9/5]
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
[3/9] from: gerardcote:sympatico:ca at: 28-Mar-2004 16:21
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
[4/9] from: moliad:aei:ca at: 29-Mar-2004 1:26
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
[5/9] from: brett:codeconscious at: 29-Mar-2004 21:23
> 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.
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.
[6/9] from: maximo:meteorstudios at: 29-Mar-2004 11:26
:-)
:-)
:-)
has that already been added to view 1.3?
or does it have an ETA!?
-MAx
---
You can either be part of the problem or part of the solution, but in the end, being
part of the problem is much more fun.
[7/9] from: gerardcote:sympatico:ca at: 29-Mar-2004 15:29
Hi Brett and Max,
Thanks for this info and the previous discussion about it. I'm glad not to be the only
one with this concern.
It's all great news.
Regards,
Gerard
Max wrote :
> > 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.
Brett replied :
[8/9] from: brett:codeconscious at: 30-Mar-2004 9:25
Sorry to get your hopes up. I don't think it means that it will be included
(actually the opposite). I wanted to point out that it has been discussed
and to show how Carl defines a dialect.
Regards,
Brett.
[9/9] from: maximo::meteorstudios::com at: 29-Mar-2004 21:22
Hi Brett,
Anyhow, at least it seems like Carl and the community are in-tune to what is improvable
with dialects. so when he does decide to reopen that part of rebol, it most probably
will solve the issues we do have, not just his own.
I think Carl has the same problem some of us have...
he only has two arms... ;-)
but he has ideas and designs for a hundred... and is a perfectionist...
One thing is obvious and that is that rebol as a platform is now, again, gaining momentum.
Specific issues are being solved, and we are now starting to see new tools, not just
fixes and projects. NEW users are always appearing, and some of them have been working
on big projects, right off the bat!
For my part, I'd like to give a firm ETA on glayout, but I've constantly been raising
the bar, so the delivery is always around the corner... And I can't catch up. ;-)
The good news is that it HAS progressed a lot. Many issues I didn't feel like solving
HAVE been solved, and its starting to feel much less like a demo/beta api and much more
like a polished tool. And since it sits on top of VID, you guys will be able to integrate
your stuff into it.
-MAx
---
You can either be part of the problem or part of the solution, but in the end, being
part of the problem is much more fun.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted