OpenEuphoria

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

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

Currently, value(), defined in get.e, takes a sequence and returns {status code,
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

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

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

CChris wrote:

> Currently, value(), defined in get.e, takes a sequence and returns {status
> code,
> 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

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

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Jun 25, 2007
• 775 views
• Last edited Jun 26, 2007

Juergen Luethje wrote:
> 
> CChris wrote:
> 
> > Currently, value(), defined in get.e, takes a sequence and returns {status
> > code,
> > 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

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.

If the "why?" refers to the duplicate modified Get(), it stems from the fact
that Get() recursively calls itself, while only the first called instance needs
to report the extra information. Hence, the original function handles the
innermost calls, and the outer one returns the extra data. That's why two
slightly different functions are needed if you wish to avoid too many flag tests
and useless calls to aux routines. For translated code, the compiler will inline
smartly enough for this not to be necessary, but interpreted code could benefit.

CChris

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

• Posted by Bernie Ryan <xotron at bluefrog.com> Jun 25, 2007
• 737 views
• Last edited Jun 26, 2007

CChris wrote:
> 
> Currently, value(), defined in get.e, takes a sequence and returns {status
> code,
> 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?


Chris:

 I would rather that value() function just return the value
 instead of sequence. The failure should fail within function with
 a message. In my experience of using the value() I have never taken
 taken any other action to the failure of the function except report
 the error and end my program. Why should a user have to write extra
 testing code just to use a basic function. This testing becomes a
 pain in the neck especially if do a great number of calls to value(). 

Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

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

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

Bernie Ryan wrote:
> 
> CChris wrote:
> > 
> > Currently, value(), defined in get.e, takes a sequence and returns {status
> > code,
> > 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?
> 
> 
> Chris:
> 
>  I would rather that value() function just return the value
>  instead of sequence. The failure should fail within function with
>  a message. In my experience of using the value() I have never taken
>  taken any other action to the failure of the function except report
>  the error and end my program. Why should a user have to write extra
>  testing code just to use a basic function. This testing becomes a
>  pain in the neck especially if do a great number of calls to value(). 
> 
> Bernie
> 
> My files in archive:
> WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 
> 
> Can be downloaded here:
> <a
> href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.co
m/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a>

Try please

function simple_value(sequence s)
s=value(s)
if s[1]!=GET_SUCCESS then
    crash_message("Error reading a value")
    abort(1)
else
    return s[2]
end if
end function    

This could even be added to get.e, if it is felt to be useful. However, I don't
like the idea of forcing a specific way to deal with errors inside a standard
library.

CChris

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

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Jun 26, 2007
• 716 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

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

• Posted by DB James <larches at comcast.net> Jun 26, 2007
• 743 views
• Last edited Jun 27, 2007

Hi.

I agree with Juergen's clearly-stated and solid reasoning on this issue.

And I do find myself thinking how at one time Robert had to go through all the
"upgrade" hassle within his own personal head, and now the process of evolving
Euphoria is a public one, and not necessarily as easy as some had assumed. But
it will happen as time goes on, and Euphoria will be the better for it.

I don't know what Robert is thinking about all this, but if it were me, I'd be
wearing a small, but discreet, smile.

--Quark

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

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

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()
> > 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.

> Although I learned now that value() can be used differently, I think
> most people use value() just for converting e.g. "12345" to 12345.

Well, more feedback wanted from the list and indirectly from others.

> 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."
> 

Sorry, but that "simple" mantra has caused Eu a lot of harm, because the user
has to code many things himself which s/he would find ready made in other
languages. Probably one of the reasons its use hardly spreads.

As for the Val() function in Basic, how does it signal an error? Further, it
doesn't decode strings if I remember corrctly. Perhaps a get_number(sequence s)
function, returning "" on error, would be useful as well, I'm not against it at
all.

> > 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</font></i>
> > 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.
> 

A non nested sequence of length 4 is more complicated than one of length 2? I
really didn't expect that one.

Could you provide an example where the proposed change breaks backward
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.
> 

You seem to have locked on the text parsing and reformatting uses, overlooking
the "simple" fact that, if a string has several object representations
concatenated inside it, the current value() doesn't allow to extract them all,
contrary to what you can do with get() on a text file.

CChris
> Regards,
>    Juergen

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

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Jun 27, 2007
• 717 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

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

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

Pete Lomax wrote:
> 
> 
> I've really only been skimming this thread, but a suggestion which just might
> possibly make everyone happy is instead of:
> }}}
<eucode>
>     return {s,v,c,l}
> </eucode>
{{{

> where c, l are local vars to count chars read, leading spaces, do this:
> }}}
<eucode>
>     return {s,v}
> ...
> global function Get_extra_info()
> -- retrieve extra info about the immediately preceding get()/value() call
> -- (if unsuccessful, it should indicate the exact point of error)
>     return {c,l} --{chars read, leading spaces}
> end function
> </eucode>
{{{

> Instead of c, I would re-use string_next (NB with changes below, now 0..len,
> was 1..len+1), and use leading_chars instead of l. In both value() and get(),
> initialise string_next to 0 and leading_chars to -1, and:
> }}}
<eucode>
> procedure get_ch()
>     if sequence(input_string) then
>         if string_next < length(input_string) then    -- (was <=)
> 	      string_next += 1                          -- (was after next)
>             ch = input_string[string_next]
>         else
> 	      ch = GET_EOF
>         end if
>     else    
>         string_next += 1                              -- (new)
>         ch = getc(input_file)
>     end if
> end procedure
> 
> procedure skip_blanks()
> -- skip white space
> -- ch is "live" at entry and exit
> 
>     while find(ch, " \t\n\r") do
>         get_ch()
>     end while
>     if leading_chars=-1 then                         -- (new)
>         leading_chars=string_next-1                  -- (new)
>     end if                                           -- (new)
> end procedure
> </eucode>
{{{

> At least I think that would do everything asked for. I don't think you need
> to modify/duplicate Get() at all. The above is just a suggestion, completely
> untested of course.
> 

The problem with this approach is that Get() calls both itself and
skip_blanks(). skip_blanks() should record stuff only on its very first
invocation. Total character count can be read right before the outermost instance
of Get() returns, so it is not affected. Use "{   2}" as a test case: leading
spaces should be 0, not 3.
To avoid the penalty of endlessly testing whether the current instance of Get()
is the outermost one, which is often false in the case of strings representing
sequences, I defined a modified Get2(), which value() calls and then calls the
regular Get() for any inner subobjects. If you prefer doing that in skip_blanks()
instead, no problem. leading_whitespace will become local instead of private to
Get2().

As for defining an extra get_read_characters(), which would return the extra
info, well I'd go with it, the job will get done. Could you explain, however, why
this alternative scheme is preferable? It makes one extra public function to
document, instead of extra returned values. Otherwise, it is completely
equivalent. Oh right, you must be careful to call get_read_characters(), if you
wish, before calling value() or get() again - I assume this is a minor issue. And
not to accidentally call get_read_characters() before value(). My proposal
avoided all these small issues.

> Someone needs to conjure up a decent test script for the changes though, one
> that ensures no existing functionality is damaged in any way whatsoever, bar
> an inevitable, tiny and utterly insignificant performance hit.

Rob, don't you have a test suite available for Euphoria? It would be a good
addition to the SVN repository. This solution would ensure a uniform level of
quality control. Tests could be freely added, but none modified or removed from
such a suite.

> 
> Now, does anyone have any objections to that?
> 
> Regards,
> Pete
> PS I have no quibble with adding Derek's routine at the same time.

CChris

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

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jun 27, 2007
• 762 views

CChris wrote:
> Could you explain, however, why this alternative scheme is preferable?
I have now totally changed my mind and gone off on a complete tangent: optional
parameters.

If Eu had optional parameters, then:

integer errcode, chars_read, lead_space
procedure value_info(sequence info)
   errcode = info[1]
   chars_read = info[2]
   lead_space = info[3]
   if errcode!=GET_SUCCESS then
      -- handle errors centrally...
   end if
end procedure
constant r_ve=routine_id("value_info")

object r
   r=value("0",r_ve)
   if errcode!=GET_SUCCESS then
       -- ... or one at a time

If you call value() with one parameter it behaves as now, for legacy code.
If you call value() with two parameters, the result is a single value like most
people expect.
Note that in this scheme, value_info() is always called, GET_SUCCESS or not.

Since optional parameters are a way off, I now change my vote to adding a
valueEx() routine which works as above.

Regards,
Pete

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

• Posted by Derek Parnell <ddparnell at bigpond.com> Jun 28, 2007
• 735 views

CChris wrote:
> Derek, will you comit your own code, or do you prefer my doing so with
> appropriate
> credits?

What exactly do you mean by "commit your code"? Are you referring to checking it
in to SourceForge? In anycase, I'd like to tidy it up before making it generally
available, including better docs.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

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

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

Derek Parnell wrote:
> 
> CChris wrote:
> > Derek, will you comit your own code, or do you prefer my doing so with
> > appropriate
> > credits?
> 
> What exactly do you mean by "commit your code"? Are you referring to checking
> it in to SourceForge? In anycase, I'd like to tidy it up before making it
> generally
> available, including better docs.
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

I was meaning, committing it to the SVN repository of Euphoria as a new routine
in get.e, since a few people have requested a function that would "simply" return
a numeric value held at the beginning of a string, more "like val() in Basic",
which i know only by name. Named get_number(sequence s), perhaps.

CChris

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

• Posted by Robert Craig <rds at RapidEuphoria.com> Jun 28, 2007
• 719 views

CChris wrote:
> Currently, value(), defined in get.e, takes a sequence and returns 
> {status code, 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?

I don't care too much, one way or the other,
since I haven't had a need for the extra information,
but I can see that if you wanted to use value() to process
a long string containing many object-representations,
like you can do with get(), then you would like to know
how many characters it read each time, so you could chop those off
the input sequence, and run value() on the rest. 

I don't think this would break any significant 
amount of existing code.

If people think this is worthwhile, then my (weak) preference 
would be:

   - go ahead, but extend get() as well, to keep the
     symmetry between get() and value()

A small point that may or may not affect you:
When get() or value() process an object representation, 
they sometimes stop reading when they see '}' or '"', 
but sometimes they must read an extra space,
e.g. for numbers like 3.33333 an extra character (e.g. blank)
might have to be consumed in order to know that you've reached 
the end of the number. There is no way for get() to push this 
character back into the input stream. This issue bothered one or 
two people in the past. i.e. a stream like {1,2,3}3.33333 can be 
read properly, but 3.33333{1,2,3} can't. That's why the docs say 
you need some whitespace between all objects in the stream.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

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

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

Robert Craig wrote:
> 
> CChris wrote:
> > Currently, value(), defined in get.e, takes a sequence and returns 
> > {status code, 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?
> 
> I don't care too much, one way or the other,
> since I haven't had a need for the extra information,
> but I can see that if you wanted to use value() to process
> a long string containing many object-representations,
> like you can do with get(), then you would like to know
> how many characters it read each time, so you could chop those off
> the input sequence, and run value() on the rest. 
> 
> I don't think this would break any significant 
> amount of existing code.
> 
> If people think this is worthwhile, then my (weak) preference 
> would be:
> 
>    - go ahead, but extend get() as well, to keep the
>      symmetry between get() and value()
> 
> A small point that may or may not affect you:
> When get() or value() process an object representation, 
> they sometimes stop reading when they see '}' or '"', 
> but sometimes they must read an extra space,
> e.g. for numbers like 3.33333 an extra character (e.g. blank)
> might have to be consumed in order to know that you've reached 
> the end of the number. There is no way for get() to push this 
> character back into the input stream. This issue bothered one or 
> two people in the past. i.e. a stream like {1,2,3}3.33333 can be 
> read properly, but 3.33333{1,2,3} can't. That's why the docs say 
> you need some whitespace between all objects in the stream.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>

As you can see, there is also an alternate scheme proposed by Pete Lomax.

I thought get() could easily say

junk=seek(input_file,where(input_file)-1))

 to back up the extra
space, if needed. This won't work with some devices of course, and there's no way
to tell whether input_file refers to a device. I don't know if anyone cares.

CChris

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

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

Robert Craig wrote:
> 
> CChris wrote:
> > Currently, value(), defined in get.e, takes a sequence and returns 
> > {status code, 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?
> 
> I don't care too much, one way or the other,
> since I haven't had a need for the extra information,
> but I can see that if you wanted to use value() to process
> a long string containing many object-representations,
> like you can do with get(), then you would like to know
> how many characters it read each time, so you could chop those off
> the input sequence, and run value() on the rest. 
> 
> I don't think this would break any significant 
> amount of existing code.
> 
> If people think this is worthwhile, then my (weak) preference 
> would be:
> 
>    - go ahead, but extend get() as well, to keep the
>      symmetry between get() and value()
> 
> A small point that may or may not affect you:
> When get() or value() process an object representation, 
> they sometimes stop reading when they see '}' or '"', 
> but sometimes they must read an extra space,
> e.g. for numbers like 3.33333 an extra character (e.g. blank)
> might have to be consumed in order to know that you've reached 
> the end of the number. There is no way for get() to push this 
> character back into the input stream. This issue bothered one or 
> two people in the past. i.e. a stream like {1,2,3}3.33333 can be 
> read properly, but 3.33333{1,2,3} can't. That's why the docs say 
> you need some whitespace between all objects in the stream.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>

I just looked at be_execute.c in this respect.

If getc() was defined as an inline function, you could remove this problem by 
* having a one char buffer for each open file (handle)
* having getc() to update this buffer on each read
* having one excess_read flag per file which says whether a character is to be
physically read from the file if clear
* causing Get() (or Get2() in my version) to attempt to back up using seek() if
it reads a pure number in a file as a top level object, and set the above flag
using a machine_proc() interface on failure to back up
* if the excess_read flag for a file is set, getc() clears it and returns the
buffered char, which was read in excess. Otherwise it behaves as usual.
* having where() to adjust its return value according to the excess_read status
for the requested file.
* having seek() to clear the flag for the file for which it is called

I am not sure whether the above can be done as getc() is a macro.
And, even if it can be done, is it worth the effort, and is there any chance of
a performance penalty in this sensitive area? I don't know C well enough, you
probably have a clearer idea. And the final answer may depend on the compiler
too.

CChris

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

• Posted by Robert Craig <rds at RapidEuphoria.com> Jun 29, 2007
• 730 views

CChris wrote:
> I just looked at be_execute.c in this respect.
> 
> If getc() was defined as an inline function, you could remove this problem by
> 
> * having a one char buffer for each open file (handle)
> * having getc() to update this buffer on each read
> * having one excess_read flag per file which says whether a character is to
> be physically read from the file if clear
> * causing Get() (or Get2() in my version) to attempt to back up using seek()
> if it reads a pure number in a file as a top level object, and set the above
> flag using a machine_proc() interface on failure to back up
> * if the excess_read flag for a file is set, getc() clears it and returns the
> buffered char, which was read in excess. Otherwise it behaves as usual.
> * having where() to adjust its return value according to the excess_read
> status
> for the requested file.
> * having seek() to clear the flag for the file for which it is called
> 
> I am not sure whether the above can be done as getc() is a macro.
> And, even if it can be done, is it worth the effort, and is there any chance
> of a performance penalty in this sensitive area? I don't know C well enough,
> you probably have a clearer idea. And the final answer may depend on the
> compiler
> too.

I thought about adding an ungetc() several years ago,
but I didn't go ahead with it because:
  - there would be added complexity and chance of subtle bugs
  - Watcom had a bug in this area
  - no one had ever asked for it
  - there would be a tiny loss of performance

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

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

• Posted by Robert Craig <rds at RapidEuph?ria.com> Jun 29, 2007
• 724 views

CChris wrote:
> 
> Robert Craig wrote:
> > 
> > CChris wrote:
> > > I just looked at be_execute.c in this respect.
> > > 
> > > If getc() was defined as an inline function, you could remove this problem
> > > by
> > > 
> > > * having a one char buffer for each open file (handle)
> > > * having getc() to update this buffer on each read
> > > * having one excess_read flag per file which says whether a character is
> > > to
> > > be physically read from the file if clear
> > > * causing Get() (or Get2() in my version) to attempt to back up using
> > > seek()
> > > if it reads a pure number in a file as a top level object, and set the
> > > above
> > > flag using a machine_proc() interface on failure to back up
> > > * if the excess_read flag for a file is set, getc() clears it and returns
> > > the
> > > buffered char, which was read in excess. Otherwise it behaves as usual.
> > > * having where() to adjust its return value according to the excess_read
> > > status
> > > for the requested file.
> > > * having seek() to clear the flag for the file for which it is called
> > > 
> > > I am not sure whether the above can be done as getc() is a macro.
> > > And, even if it can be done, is it worth the effort, and is there any
> > > chance
> > > of a performance penalty in this sensitive area? I don't know C well
> > > enough,
> > > you probably have a clearer idea. And the final answer may depend on the
> > > compiler
> > > too.
> > 
> > I thought about adding an ungetc() several years ago,
> > but I didn't go ahead with it because:
> >   - there would be added complexity and chance of subtle bugs
> >   - Watcom had a bug in this area
> >   - no one had ever asked for it
> >   - there would be a tiny loss of performance
> > 
> > Regards,
> >    Rob Craig
> >    Rapid Deployment Software
> >    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> 
> Understandable.
> Do you think the mod above, which is a virtual ungetc() not relying on the
> compiler's
> library, and with very restricted capabilities, would be useful? At least, it
> would correct the issue of the extra space get() reads.
> I forgot to mention that EOpen() should clear the flag for the concened file.

I think it would be a rather complicated and bug-prone change.
Probably not worth the trouble. 

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com