1. get() and value()
Since no one has made any comment on this for the last 8 days or perhaps more,
I'm going to proceed...
* get() and value() will keep returning a 2 element sequence.
* get() and value() accept embedded comments in sequence - they crash in
official Eu, which some don't see as a bug;
* get() and value() ignore leading top level comments. Commments start by "--"
and end a a \n or \r character, or at end of input;
* a new value_from(sequence s,integer starting_point) will allow to scan a
sequence from a starting point between 1 and length(s). This function returns a 4
element sequence: first two as value(), total character read, leading whitespace.
* There's no symmetric get_from(), as it would reduce to a possibly inefficient
sequence of seek() and get(), unless there's some demand for it.
Additionally, the possibility exists for all of the above to return a new error
code when no value is read and end of input is reached, as opposed to having read
an unfinished value string. Currently, GET_EOF is returned in both case. Adding
the extra error code would remove 4-5 lines of code from get.e. Is this to be
considered?
I'll update the whole thing tonight (4pm now).
CChris
2. Re: get() and value()
CChris wrote:
> Since no one has made any comment on this for the last 8 days or perhaps more,
> I'm going to proceed...
>
> * get() and value() will keep returning a 2 element sequence.
I don't think anyone will disagree with that.
> * get() and value() accept embedded comments in sequence - they crash in
> official
> Eu, which some don't see as a bug;
> * get() and value() ignore leading top level comments. Commments start by "--"
> and end a a \n or \r character, or at end of input;
I don't think anyone will mind if comments in the input data
are accepted, and ignored.
I've actually had occasions where I would have liked to
add comments to my input data.
> * a new value_from(sequence s,integer starting_point) will allow to scan a
> sequence
> from a starting point between 1 and length(s). This function returns a 4
> element
> sequence: first two as value(), total character read, leading whitespace.
Sounds useful.
> * There's no symmetric get_from(), as it would reduce to a possibly
> inefficient
> sequence of seek() and get(), unless there's some demand for it.
OK.
> Additionally, the possibility exists for all of the above to return a new
> error
> code when no value is read and end of input is reached, as opposed to having
> read an unfinished value string. Currently, GET_EOF is returned in both case.
> Adding the extra error code would remove 4-5 lines of code from get.e. Is this
> to be considered?
Sounds OK.
> I'll update the whole thing tonight (4pm now).
Go ahead with all of this,
unless someone seriously disagrees very soon.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: get() and value()
- Posted by Juergen Luethje <j.lue at gm?.?e>
Aug 23, 2007
-
Last edited Aug 24, 2007
Robert Craig wrote:
> CChris wrote:
> > Since no one has made any comment on this for the last 8 days or perhaps
> > more,
> > I'm going to proceed...
> >
> > * get() and value() will keep returning a 2 element sequence.
>
> I don't think anyone will disagree with that.
>
> > * get() and value() accept embedded comments in sequence - they crash in
> > official
> > Eu, which some don't see as a bug;
> > * get() and value() ignore leading top level comments. Commments start by
> > "--"
> > and end a a \n or \r character, or at end of input;
>
> I don't think anyone will mind if comments in the input data
> are accepted, and ignored.
> I've actually had occasions where I would have liked to
> add comments to my input data.
>
> > * a new value_from(sequence s,integer starting_point) will allow to scan a
> > sequence
> > from a starting point between 1 and length(s). This function returns a 4
> > element
> > sequence: first two as value(), total character read, leading whitespace.
>
> Sounds useful.
>
> > * There's no symmetric get_from(), as it would reduce to a possibly
> > inefficient
> > sequence of seek() and get(), unless there's some demand for it.
>
> OK.
>
> > Additionally, the possibility exists for all of the above to return a new
> > error
> > code when no value is read and end of input is reached, as opposed to having
> > read an unfinished value string. Currently, GET_EOF is returned in both
> > case.
> > Adding the extra error code would remove 4-5 lines of code from get.e. Is
> > this
> > to be considered?
>
> Sounds OK.
>
> > I'll update the whole thing tonight (4pm now).
>
> Go ahead with all of this,
> unless someone seriously disagrees very soon.
I generally disagree with "playing with the interpreter" unless there
is actually a good reason for doing so (and provided that the person who
makes the changes has complete overview about what s/he is doing!).
A good reason would be e.g. when a majority of EUforum users would
appreciating the proposed changes. I haven't read something like that
concerning this proposal.
Regards,
Juergen
4. Re: get() and value()
- Posted by Derek Parnell <ddparnell at ??gpond.com>
Aug 23, 2007
-
Last edited Aug 24, 2007
CChris wrote:
> I'll update the whole thing tonight (4pm now).
Please remember that we don't all live in your time zone.
I have no objections because I choose not to use any of these functions.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
5. Re: get() and value()
Juergen Luethje wrote:
>
> Robert Craig wrote:
>
> > CChris wrote:
> > > Since no one has made any comment on this for the last 8 days or perhaps
> > > more,
> > > I'm going to proceed...
> > >
> > > * get() and value() will keep returning a 2 element sequence.
> >
> > I don't think anyone will disagree with that.
> >
> > > * get() and value() accept embedded comments in sequence - they crash in
> > > official
> > > Eu, which some don't see as a bug;
> > > * get() and value() ignore leading top level comments. Commments start by
> > > "--"
> > > and end a a \n or \r character, or at end of input;
> >
> > I don't think anyone will mind if comments in the input data
> > are accepted, and ignored.
> > I've actually had occasions where I would have liked to
> > add comments to my input data.
> >
> > > * a new value_from(sequence s,integer starting_point) will allow to scan a
> > > sequence
> > > from a starting point between 1 and length(s). This function returns a 4
> > > element
> > > sequence: first two as value(), total character read, leading whitespace.
> >
> > Sounds useful.
> >
> > > * There's no symmetric get_from(), as it would reduce to a possibly
> > > inefficient
> > > sequence of seek() and get(), unless there's some demand for it.
> >
> > OK.
> >
> > > Additionally, the possibility exists for all of the above to return a new
> > > error
> > > code when no value is read and end of input is reached, as opposed to
> > > having
> > > read an unfinished value string. Currently, GET_EOF is returned in both
> > > case.
> > > Adding the extra error code would remove 4-5 lines of code from get.e. Is
> > > this
> > > to be considered?
> >
> > Sounds OK.
> >
> > > I'll update the whole thing tonight (4pm now).
> >
> > Go ahead with all of this,
> > unless someone seriously disagrees very soon.
>
> I generally disagree with "playing with the interpreter" unless there
> is actually a good reason for doing so (and provided that the person who
> makes the changes has complete overview about what s/he is doing!).
> A good reason would be e.g. when a majority of EUforum users would
> appreciating the proposed changes. I haven't read something like that
> concerning this proposal.
He isn't playing with the interpreter,
just the get.e include file.
get() and value() are implemented in get.e in 100% Euphoria code.
However, if you want, we can have an official vote
on the above changes. Yes or No on the whole set above.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: get() and value()
Robert Craig wrote:
>
> Juergen Luethje wrote:
> >
> > Robert Craig wrote:
> >
> > > CChris wrote:
> > > > Since no one has made any comment on this for the last 8 days or perhaps
> > > > more,
> > > > I'm going to proceed...
> > > >
> > > > * get() and value() will keep returning a 2 element sequence.
> > >
> > > I don't think anyone will disagree with that.
> > >
> > > > * get() and value() accept embedded comments in sequence - they crash in
> > > > official
> > > > Eu, which some don't see as a bug;
> > > > * get() and value() ignore leading top level comments. Commments start
> > > > by "--"
> > > > and end a a \n or \r character, or at end of input;
> > >
> > > I don't think anyone will mind if comments in the input data
> > > are accepted, and ignored.
> > > I've actually had occasions where I would have liked to
> > > add comments to my input data.
> > >
> > > > * a new value_from(sequence s,integer starting_point) will allow to scan
> a sequence</font></i>
> > > > from a starting point between 1 and length(s). This function returns a 4
> > > > element
> > > > sequence: first two as value(), total character read, leading
> > > > whitespace.
> > >
> > > Sounds useful.
> > >
> > > > * There's no symmetric get_from(), as it would reduce to a possibly
> > > > inefficient
> > > > sequence of seek() and get(), unless there's some demand for it.
> > >
> > > OK.
> > >
> > > > Additionally, the possibility exists for all of the above to return a
> > > > new error
> > > > code when no value is read and end of input is reached, as opposed to
> > > > having
> > > > read an unfinished value string. Currently, GET_EOF is returned in both
> > > > case.
> > > > Adding the extra error code would remove 4-5 lines of code from get.e.
> > > > Is this
> > > > to be considered?
> > >
> > > Sounds OK.
> > >
> > > > I'll update the whole thing tonight (4pm now).
> > >
> > > Go ahead with all of this,
> > > unless someone seriously disagrees very soon.
> >
> > I generally disagree with "playing with the interpreter" unless there
> > is actually a good reason for doing so (and provided that the person who
> > makes the changes has complete overview about what s/he is doing!).
> > A good reason would be e.g. when a majority of EUforum users would
> > appreciating the proposed changes. I haven't read something like that
> > concerning this proposal.
>
> He isn't playing with the interpreter,
> just the get.e include file.
> get() and value() are implemented in get.e in 100% Euphoria code.
>
> However, if you want, we can have an official vote
> on the above changes. Yes or No on the whole set above.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Hello all,
My vote.
I'm dead set against anything the make old code not work anymore in new
versions.
Don Cole
7. Re: get() and value()
Robert Craig wrote:
> Juergen Luethje wrote:
> >
> > Robert Craig wrote:
> >
> > > CChris wrote:
> > > > Since no one has made any comment on this for the last 8 days or perhaps
> > > > more,
> > > > I'm going to proceed...
> > > >
> > > > * get() and value() will keep returning a 2 element sequence.
> > >
> > > I don't think anyone will disagree with that.
> > >
> > > > * get() and value() accept embedded comments in sequence - they crash in
> > > > official
> > > > Eu, which some don't see as a bug;
> > > > * get() and value() ignore leading top level comments. Commments start
> > > > by "--"
> > > > and end a a \n or \r character, or at end of input;
> > >
> > > I don't think anyone will mind if comments in the input data
> > > are accepted, and ignored.
> > > I've actually had occasions where I would have liked to
> > > add comments to my input data.
> > >
> > > > * a new value_from(sequence s,integer starting_point) will allow to scan
> a sequence</font></i>
> > > > from a starting point between 1 and length(s). This function returns a 4
> > > > element
> > > > sequence: first two as value(), total character read, leading
> > > > whitespace.
> > >
> > > Sounds useful.
> > >
> > > > * There's no symmetric get_from(), as it would reduce to a possibly
> > > > inefficient
> > > > sequence of seek() and get(), unless there's some demand for it.
> > >
> > > OK.
> > >
> > > > Additionally, the possibility exists for all of the above to return a
> > > > new error
> > > > code when no value is read and end of input is reached, as opposed to
> > > > having
> > > > read an unfinished value string. Currently, GET_EOF is returned in both
> > > > case.
> > > > Adding the extra error code would remove 4-5 lines of code from get.e.
> > > > Is this
> > > > to be considered?
> > >
> > > Sounds OK.
> > >
> > > > I'll update the whole thing tonight (4pm now).
> > >
> > > Go ahead with all of this,
> > > unless someone seriously disagrees very soon.
> >
> > I generally disagree with "playing with the interpreter" unless there
> > is actually a good reason for doing so (and provided that the person who
> > makes the changes has complete overview about what s/he is doing!).
> > A good reason would be e.g. when a majority of EUforum users would
> > appreciating the proposed changes. I haven't read something like that
> > concerning this proposal.
>
> He isn't playing with the interpreter,
> just the get.e include file.
> get() and value() are implemented in get.e in 100% Euphoria code.
I see. If this will not change the interpreter, then I don't care.
Regards,
Juergen
8. Re: get() and value()
Robert Craig wrote:
>
> Juergen Luethje wrote:
> >
> > Robert Craig wrote:
> >
> > > CChris wrote:
> > > > Since no one has made any comment on this for the last 8 days or perhaps
> > > > more,
> > > > I'm going to proceed...
> > > >
> > > > * get() and value() will keep returning a 2 element sequence.
> > >
> > > I don't think anyone will disagree with that.
> > >
> > > > * get() and value() accept embedded comments in sequence - they crash in
> > > > official
> > > > Eu, which some don't see as a bug;
> > > > * get() and value() ignore leading top level comments. Commments start
> > > > by "--"
> > > > and end a a \n or \r character, or at end of input;
> > >
> > > I don't think anyone will mind if comments in the input data
> > > are accepted, and ignored.
> > > I've actually had occasions where I would have liked to
> > > add comments to my input data.
> > >
> > > > * a new value_from(sequence s,integer starting_point) will allow to scan
> a sequence</font></i>
> > > > from a starting point between 1 and length(s). This function returns a 4
> > > > element
> > > > sequence: first two as value(), total character read, leading
> > > > whitespace.
> > >
> > > Sounds useful.
> > >
> > > > * There's no symmetric get_from(), as it would reduce to a possibly
> > > > inefficient
> > > > sequence of seek() and get(), unless there's some demand for it.
> > >
> > > OK.
> > >
> > > > Additionally, the possibility exists for all of the above to return a
> > > > new error
> > > > code when no value is read and end of input is reached, as opposed to
> > > > having
> > > > read an unfinished value string. Currently, GET_EOF is returned in both
> > > > case.
> > > > Adding the extra error code would remove 4-5 lines of code from get.e.
> > > > Is this
> > > > to be considered?
> > >
> > > Sounds OK.
> > >
> > > > I'll update the whole thing tonight (4pm now).
> > >
> > > Go ahead with all of this,
> > > unless someone seriously disagrees very soon.
> >
> > I generally disagree with "playing with the interpreter" unless there
> > is actually a good reason for doing so (and provided that the person who
> > makes the changes has complete overview about what s/he is doing!).
> > A good reason would be e.g. when a majority of EUforum users would
> > appreciating the proposed changes. I haven't read something like that
> > concerning this proposal.
>
> He isn't playing with the interpreter,
> just the get.e include file.
> get() and value() are implemented in get.e in 100% Euphoria code.
>
> However, if you want, we can have an official vote
> on the above changes. Yes or No on the whole set above.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Hello,
Originally the question was: Do you agree with the changes in get()
and value()? In the thread "get() and value()".
This thread has broken down into 6 sub threads;
[POLL] Sequence of types
Voting
Discusion concerning [POLL] Sequence of types
Proposal for 'math.e'(2007-08-23)
Frozen language versions
Process
Whew!!!, I's no wonder nothing gets done around here.
Don Cole
