OpenEuphoria

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

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

Juergen Luethje wrote:
> 
> CChris wrote:
> 
> > Juergen Luethje wrote:
> > > 
> > > CChris wrote:
> > > 
> > > > Currently, value(), defined in get.e, takes a sequence and returns
> > > > {status
> code,</font></i>
> > > > value read}.
> > > > The proposed enhancement is to return 
> > > > {status code,
> > > >  value read,
> > > >  number of characters read,
> > > >  number of leading whitespace characters}.
> > > > 
> > > > This can be done at the cost of creating a duplicated, slightly modified
> > > > copy
> > > > of the internal Get() function, so that performance won't be affacted at
> > > > all.
> > > > get() won't be affected, since where() will give you most of the same
> > > > information.
> > > > 
> > > > Any thoughts? issues? other suggestions?
> > > > CChris
> > > 
> > > Why?
> > > 
> > > Regards,
> > >    Juergen
> 
> I'm sorry, I better should have written a whole sentence. 
> My intended question was: Why do you want to change the value() function in
> the proposed way?
> 
> > Because, when you wish to process text, you have to search for some free
> > format
> > stuff and replace only the exact right portion by something. value()
> > currently
> > does not return the information, but it is hidden in local vars in get.e.
> > The
> > idea is simply to make the extra information available, as it is sometimes
> > useful.
> > I have quite often wished I didn't have to code my own version of value()
> > for
> > that purpose.
> 
> I think that I still don't understand. As far as I can see, value() is not
> meant
> for
> text processing or text parsing, but just for conversion of strings such as
> "12345"
> to numeric values.
> 
> <snip>
> 
> Regards,
>    Juergen

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. If I say }}}
<eucode>x=value({34,65,66,67,34})</eucode>
{{{
, 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.

Since where() tells you how many characters get() just read, the need to return
this extra information is less immediate, which is why I apparently broke the
symmetry and left get() alone. I say "apparently" because, on the other hand, it
makes a string look more like a file, with zero or more objects stored in it as
plain text. Hence another symmetry get stronger in the process.

I hope this is a clear and precise enough rationale. Please tell us if it still
looks wrong.

CChris