OpenEuphoria

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

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