OpenEuphoria

Re: Proposal for a (small) enhancement to the value() function.

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Jun 27, 2007
• 679 views

Derek Parnell wrote:
> 
> CChris wrote:
> > 
> > Juergen Luethje wrote:
> > > 
> > > I see now what you mean. However, I still don't know whether it's a good
> > > idea to change the value() function in the proposed way.
> > > 
> > > CChris wrote:
> > > 
> > > > value() is meant to read any Euphoria object out of a string, the same
> > > > way
> get()</font></i>
> > > > reads it out of a file, as written in the docs. This has nothing to do
> > > > with
> > > > numeric values.
> > > 
> > > Of course value() has got something to do with numeric values.
> > 
> > Barely, and not mainly. A least, I have hardly ever used it for that
> > purpose.
> 
> Wow! I never knew it was a general purpose routine. I thought it only
> converted
> a string to a number and I've only ever used it for that purpose.
> 
> But I don't like it much as it doesn't handle a whole lot of potential error
> conditions so I use my own toNumber() function. 
> 
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

The following also complements my last reply to Juergen. I can't reply to both
posts at the same time though....

The following is a quote from the official documentation, taken from the entry
for value():
<quote>
Description: Read the string representation of a Euphoria object, and compute
the value of that object. A 2-element sequence, {error_status, value} is actually
returned,
</quote>
[snipped status code list]

As a result, I don't understand the point about numeric values for value(), nor
why it should be restricted to such.

And I don't understand either why a length 4 sequence is "more complicated" than
a sequence of length 2, both being not nested.

Further, the same documentation says:
<quote>
Comments: This works the same as get(), but it reads from a string that you
supply, rather than from a file or device.
</quote>
This is not true currently, because get() enables to read successive object
representations, while value() always reads the one that starts the string. To
proceed to the next object substring, you have to know how many characters were
used, but this information is not available. The proposed change aims at making
it available instead, and making the abovementioned statement in the official
documentation true.

As I said, if the need for a specialised get_number() or something, more like
Basic's Val(), is being felt (seems so), then I have no qualms about also adding
it to get.e. On the other hand, blocking or restricting value() is not something
I'd agree with.

And that get_number() could simply be your toNumber() routine, Derek, as I quite
agree on your statement about value() error reporting being too much coarse.

CChris