OpenEuphoria

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

• Posted by Juergen Luethje <j.lue at gmx.de> Jun 26, 2007
• 740 views

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()
> 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.
Although I learned now that value() can be used differently, I think
most people use value() just for converting e.g. "12345" to 12345.
And when I recall what people wrote on EUforum during the last years,
there was the wish for a _simpler_ value() function now and then.
On the RDS homepage it reads: "Simpler than Basic". Now imagine somone
who knows some Basic flavour and makes her/his first experiences with
Euphoria. S/he is looking for the Euphoria equivalent of Basic's val()
and finds in the documentation something like:
| s = value(st)
| where s consists ofthe following elements:
|  {status code,
|   value read,
|   number of characters read,
|   number of leading whitespace characters}

The person probably will think: "Simpler than Basic?? Can only be a joke."

> If I say x=value({34,65,66,67,34}),
> I get {0,"ABC"} in x, which translates into having read the sequence "ABC".
> Not a numeric value, but the expected one. One has value(sprint(x))={0,x}
> always, while
> sprint(value(s)[2]),
> if the syntax were valid and s represents a valid object,
> is a compressed form of s with all syntactically useless whitespace removed.
> 
> The only point is to make value() to also return information on its reading
> job. This is very useful, since a string may contain several consecutive valid
> string representations of Euphoria objects. This information is available
> inside
> get.e; I'm making it available outside it. The main reason I had needed this
> is related to text parsing, but more applications can be thought of. Besides,
> there is no Euphoria standard function which is "meant for text processing or
> text parsing", so it seems natural to extend value() this way, and does not
> break any language design logic.

Even with your proposed change, value() would not become a "full-blown"
text parsing function. I.e. for most text parsing needs additional
functions will be required anyway. So I see no advantage in making value()
more complicated then necessary, thereby breaking backwards compatibility.

Also, there are already text-parsing routines in the User contributions.
If you think such function(s) should be included in the official Euphoria
release, then it would be much better to provide new, really powerful and
versatile text parsing functions, which also will have appropriate names
that reflect the purpose of the functions.

Regards,
   Juergen