1. Last Element Notation
Robert,
AAARRRGRGGRRGGR!!!!
Please, please, reconsider some syntax notational assistance for accessing
the last element in a sequence!
The current piece I'm working on often needs to reference the last element
of a sequence, and often that is a deeply nested sequence. This causes the
program code to become VERY VERY *&%$ at &!* at ^ unreadable. Sure, I can write
some neat routines that do this but I'm trying to avoid the overhead
(however bloody slight) of a routine call.
So that this ...
FB_Content[lBuffer][lLine] = FB_Content[lBuffer][lLine][1..lCol-1] &
pText &
FB_Content[lBuffer][lLine][lCol..length(FB_Content[lBuffer][lLine])]
can become something like ...
FB_Content[lBuffer][lLine] = FB_Content[lBuffer][lLine][1..lCol-1] &
pText &
FB_Content[lBuffer][lLine][lCol..$]
or even better, a couple of built-in routines...
FB_Content[lBuffer][lLine] = insert(FB_Content[lBuffer][lLine], lCol,
pText)
and to simplify the extremely common idiom of removing the last element...
if equal(pText[i][$], '\n') then
pText[i] = remove_right(pText[i], 1)
end if
instead of the hard-to-read ...
if equal(pText[i][length(pText[i])], '\n') then
pText[i] = pText[i][1..length(pText[i])-1]
end if
Its little things like this that make Euphoria so frustrating, when the
solution, from the point of view of your customers, is so simple. Please
help us.
--
cheers,
Derek Parnell
2. Re: Last Element Notation
Derek Parnell wrote:
> Please, please, reconsider some syntax notational assistance for
> accessing the last element in a sequence!
OK.
I know it's awkward sometimes.
> The current piece I'm working on often needs to reference the last
> element of a sequence, and often that is a deeply nested sequence. This
> causes the program code to become VERY VERY *&%$ at &!* at ^ unreadable. Sure,
>
> I can write some neat routines that do this but I'm trying to avoid the
> overhead (however bloody slight) of a routine call.
>
>
> So that this ...
>
> FB_Content[lBuffer][lLine] = FB_Content[lBuffer][lLine][1..lCol-1] &
> pText &
>
> FB_Content[lBuffer][lLine][lCol..length(FB_Content[lBuffer][lLine])]
>
> can become something like ...
>
> FB_Content[lBuffer][lLine] = FB_Content[lBuffer][lLine][1..lCol-1] &
> pText &
> FB_Content[lBuffer][lLine][lCol..$]
Unless someone has a better idea, I think I'll go ahead
with this idea of $ meaning "the index of the last element".
e.g.
s[1..$]
s[1..$-1]
s[$-2]
etc.
I've wanted to do something like this for quite a while,
but I always had the feeling there might be a better way.
> or even better, a couple of built-in routines...
>
> FB_Content[lBuffer][lLine] = insert(FB_Content[lBuffer][lLine], lCol,
> pText)
>
> and to simplify the extremely common idiom of removing the last element...
>
> if equal(pText[i][$], '\n') then
> pText[i] = remove_right(pText[i], 1)
> end if
>
> instead of the hard-to-read ...
>
> if equal(pText[i][length(pText[i])], '\n') then
> pText[i] = pText[i][1..length(pText[i])-1]
> end if
>
> Its little things like this that make Euphoria so frustrating, when the
> solution, from the point of view of your customers, is so simple. Please
> help us.
I'll add some sequence operations like this
as routines in misc.e. I can use your recent contribution file
as a guide.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Last Element Notation
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Last Element Notation
>
>
> Derek Parnell wrote:
> > Please, please, reconsider some syntax notational assistance for
> > accessing the last element in a sequence!
>
> OK.
[snip]
Thank you, Robert. Very much appreciated.
> I'll add some sequence operations like this
> as routines in misc.e. I can use your recent contribution file
> as a guide.
You're welcome.
--
Derek
4. Re: Last Element Notation
On Wed, 17 Sep 2003 14:15:24 -0400, Robert Craig
<rds at RapidEuphoria.com> wrote:
>
>Unless someone has a better idea, I think I'll go ahead
>with this idea of $ meaning "the index of the last element".
>e.g.
> s[1..$]
> s[1..$-1]
> s[$-2]
>etc.
>
>I've wanted to do something like this for quite a while,
>but I always had the feeling there might be a better way.
>
Since you asked, I'm [still] sold on negative indexes:
s=3D"(0,0)"
x=3Ds[1..-1] -- x is now "(0,0)"
x=3Ds[2..-2] -- x is now "0,0"
x=3Ds[3..-3] -- x is now ","
s=3D"abc.exw"
if equal(s[1..3],"abc") then -- this is true
if equal(s[-3..-1],"exw") then -- this is true
s=3Ds[3..-1] -- removes the first two elements of s
s=3Ds[1..-3] -- removes the last two elements of s
s=3Ds[1..2] -- selects the first two elements of s
s=3Ds[-2..-1] -- selects the last two elements of s
"end" may be a more readable alternative to $.=20
When "end" is between [] should be no major parsing problem?
If end/$ is internally treated as -1, this fits nicely with negative
index handling.
I think there is a nice symmetry there, even if no-one else does.
Regards,
Pete
5. Re: Last Element Notation
Hello all,
I'd like the following solution:
----- code
atom L
type sequence_with_L(object a)
if sequence(a) then
L = length(a)
if L then return 1
else return 0 end if
else return 0 end if
end type
atom M
type sequence_with_M(object a)
if sequence(a) then
M = length(a)
if M then return 1
else return 0 end if
else return 0 end if
end type
atom N
type sequence_with_N(object a)
if sequence(a) then
N = length(a)
if N then return 1
else return 0 end if
else return 0 end if
end type
sequence_with_L xx_L
sequence_with_M yy_M
sequence_with_N zz_N
xx_L = {3,2,1}
yy_M = {4,5,6}
zz_N = {1,2,3}
? xx_L
? yy_M
? zz_N
? xx_L[L-1]
? yy_M[2..M]
? zz_N[N-3]
------ end of code
This approach seems handy for me and
doesn't affect the normal sequences.
Regards,
Igor Kachan
kinz at peterlink.ru
6. Re: Last Element Notation
Al wrote:
<snip>
> Also interesting is:
>
> s={1,2,3,4,5}
>
> s=s[1..2..4..5] --takes 4 arguments
> or
> s=s[1..2,4..5] --comma separation
>
> both of which would make s equal to:
> {1,2,4,5}
>From a logical point of view, the first example IMHO would/should _not_
make s equal to {1,2,4,5}. This is because '..' means 'from..to'.
So '[1..2..4..5]' would mean 'from 1 via 2 via 4 to 5', i.e.
s[1..2..4..5] = s[1..5] (= s, in this case). 
The second example, using comma separation, looks consistant with the
Euphoria syntax to me, though. I think this is a very cool idea.
> That would take care of removal too!
Yes, and it does so in an elegant and Euphorian way, IMHO.
Regards,
Juergen
--
The difference between men and boys
is the price of their toys.
7. Re: Last Element Notation
Pete wrote:
> On Wed, 17 Sep 2003 14:15:24 -0400, Robert Craig
> <rds at RapidEuphoria.com> wrote:
>
>>
>> Unless someone has a better idea, I think I'll go ahead
>> with this idea of $ meaning "the index of the last element".
>> e.g.
>> s[1..$]
>> s[1..$-1]
>> s[$-2]
>> etc.
Very nice!
Generally speaking, I would prefer the Greek omega character (well known
as symbol for 'end') to '$', but unfortunately the omega character isn't
included in the ASCII range from 0 to 127.
>> I've wanted to do something like this for quite a while,
>> but I always had the feeling there might be a better way.
>>
> Since you asked, I'm [still] sold on negative indexes:
>
> s="(0,0)"
> x=s[1..-1] -- x is now "(0,0)"
> x=s[2..-2] -- x is now "0,0"
> x=s[3..-3] -- x is now ","
>
> s="abc.exw"
> if equal(s[1..3],"abc") then -- this is true
> if equal(s[-3..-1],"exw") then -- this is true
>
> s=s[3..-1] -- removes the first two elements of s
> s=s[1..-3] -- removes the last two elements of s
>
> s=s[1..2] -- selects the first two elements of s
> s=s[-2..-1] -- selects the last two elements of s
I like negative indexes, too. But I don't know, whether or not I like
them more than the '$' notation.
I often have code such as the following:
sequence s, t
integer p
s = "Hello there - have a nice day!"
p = find('-', s) - 1
if p = -1 then
p = length(s)
end if
t = s[1..p]
If s[1..-1] means the same as s[1..length(s)], then this code snippet
could be written shorter:
sequence s, t
integer p
s = "Hello there - have a nice day!"
p = find('-', s) - 1
t = s[1..p]
Or even shorter:
sequence s, t
s = "Hello there - have a nice day!"
t = s[1..find('-', s)-1]
Cool, eh?
But I don't know, whether this might be confusing for Euphoria newbies.
> "end" may be a more readable alternative to $.
Yes.
I also have thought about EOS ('End Of Sequence'), but I don't regard
this as a good idea myself.
> When "end" is between [] should be no major parsing problem?
>
> If end/$ is internally treated as -1, this fits nicely with negative
> index handling.
>
> I think there is a nice symmetry there, even if no-one else does.
I also think so.
Regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
8. Re: Last Element Notation
Robert Craig wrote:
> Unless someone has a better idea, I think I'll go ahead
> with this idea of $ meaning "the index of the last element".
> e.g.
> s[1..$]
> s[1..$-1]
> s[$-2]
> etc.
I agree that this is probably the best notation. There are shorter notations
(for example, see Python), but they lack the clarity of the '$' notation.
The only real complaint is that it's another step toward the Perlification of
the language. The 'end' token would be more clear:
s[1..end]
s[1..end-1]
s[end-2]
but I have difficulty convincing myself that this is much better, especially
given that 'end' already has a distinct meaning in Euphoria. And the '$' is
shorter and easy to see.
Besides, If it were *true* Perlification, you'd have selected the '^' token.
-- David Cuny
9. Re: Last Element Notation
On Fri, 19 Sep 2003 12:30:42 +0000, Al Getz <Xaxo at aol.com> wrote:
>Rob had said he doesnt like this idea because he's
>checking for negative sequence refs as an error and
>apparently he doesnt know how to change to NOT checking
>for negative numbers as errors.
I would trust Rob understands that all you need is:
if idx<0 then idx+=3Dlength()+1 end if
followed by normal bounds checking.
>
>sequence s
>s=3D{1,2,3,4}
>
>[1]
>s=3Ds[-3,-1]
>
>[2]
>s=3Ds[$-4,$-2]
Actually, that should be s[$-2,$] 
)
>The only problem that would be left then would be what
>to do about <snip>:
>
>s=3Ds[4-8,-1]
>
>which generates [-4,-1] ?
Mirror or reverse indexing should not stop bounds checking.
In existing Eu, if length(s) is 4, then idx<=3D0 or idx>=3D5 error.
Permitting backward indexes (LOL!) would change this to:
idx<=3D-5 or idx=3D0 or idx>=3D5 error.
So it doubles the number of index values which don't cause an error,
but you still get a bounds check on anything clearly out of range, and
importantly, still on s[0].
>This would have to trigger an error by way of=20
>adding the lenght of the sequence to each number
>and comparing with zero to determine if the
>reference is indeed too negative.
As I said above, inverse or transpose indexes need just:
if idx<0 then idx+=3Dlength()+1
-- followed by normal index bounds checking
Whatever performance overhead that is, it is certain to be less than
remembering which [] the current $ applies to, imo.
Of course if people really like the $ symbol, and internally it simply
meant -1, they could use it in exactly the same way as proposed.=20
I have no problem with that.
Pete
10. Re: Last Element Notation
David wrote:
> Robert Craig wrote:
>
>> Unless someone has a better idea, I think I'll go ahead
>> with this idea of $ meaning "the index of the last element".
>> e.g.
>> s[1..$]
>> s[1..$-1]
>> s[$-2]
>> etc.
>
> I agree that this is probably the best notation. There are shorter notations
> (for example, see Python), but they lack the clarity of the '$' notation.
>
> The only real complaint is that it's another step toward the Perlification of
> the language. The 'end' token would be more clear:
>
> s[1..end]
> s[1..end-1]
> s[end-2]
>
> but I have difficulty convincing myself that this is much better, especially
> given that 'end' already has a distinct meaning in Euphoria. And the '$' is
> shorter and easy to see.
How about using this, in order to prevent Perlification:
s[1..fin]
s[1..fin-1]
s[fin-2]
AFAIR 'fin' often appeared at the end of old movies.
> Besides, If it were *true* Perlification, you'd have selected the '^' token.
>
> -- David Cuny
Regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
11. Re: Last Element Notation
Me wrote:
> David wrote:
>
>> Robert Craig wrote:
>>
>>> Unless someone has a better idea, I think I'll go ahead
>>> with this idea of $ meaning "the index of the last element".
>>> e.g.
>>> s[1..$]
>>> s[1..$-1]
>>> s[$-2]
>>> etc.
>>
>> I agree that this is probably the best notation. There are shorter notations
>> (for example, see Python), but they lack the clarity of the '$' notation.
>>
>> The only real complaint is that it's another step toward the Perlification of
>> the language. The 'end' token would be more clear:
>>
>> s[1..end]
>> s[1..end-1]
>> s[end-2]
>>
>> but I have difficulty convincing myself that this is much better, especially
>> given that 'end' already has a distinct meaning in Euphoria. And the '$' is
>> shorter and easy to see.
>
> How about using this, in order to prevent Perlification:
> s[1..fin]
> s[1..fin-1]
> s[fin-2]
>
> AFAIR 'fin' often appeared at the end of old movies.
>
>> Besides, If it were *true* Perlification, you'd have selected the '^' token.
>>
>> -- David Cuny
Or how about this:
s[1..last]
s[1..last-1]
s[last-2]
Regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
12. Re: Last Element Notation
--- David Cuny wrote:
>
> Robert Craig wrote:
>
> > Unless someone has a better idea, I think I'll go ahead
> > with this idea of $ meaning "the index of the last element".
>
> Besides, If it were *true* Perlification, you'd have selected the '^' token.
For Perlification, wouldn't he have chosen '$' *and* '^'?
Matt Lewis
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
13. Re: Last Element Notation
Juergen,
I do like your ideas of using fin and last as keywords instead of $.
The problem there is backwards compatibility. I have used last as a variable
name in many files, so using that as a keyword might break things. fin as well
(see, fin = File INput).
Of course, thats a minor issue (is it really so hard to change all fin to
fin_ and all last to last_ (or even fin___ and last___)?). Still, it may
prove just enough to prevent the addition of a new keyword into the language.
jbrown
--
"The dead are the only ones immortal." - Someone
14. Re: Last Element Notation
I Propose @ for last element notation.
The ~ and | keys move about the different computer keyboards.
of course. WinDOS programmers will know where to find |
because it shares the same key as \. Many programmers won't
be able to find ~ because they simply don't use it for
anything.
I don't like | for length(s). Nor do I like any of the following. :'`^!
Let me look at some here.
seq[@]
seq[?]
seq[_]
seq[$]
They all look pretty ugly too me. I like ? better than $. I feel _ is
nearly invisible. I guess @ is ok. It makes [] look a bit full though.
Let's see.
seq[1..@-2]
seq[1..?-2]
seq[1..$-2]
Now I like @ best and then $, but ? looks really funny. I can't
think of a reason why we can't use @ or why it shouldn't be use.
Lucius L. Hilley III
15. Re: Last Element Notation
>
> I Propose @ for last element notation.
I'm not wedded to '$'. I only suggested it because I'm used to Unix regular
expressions where the '$' is used to reference the end of a pattern. No other
reason really.
--
Derek
16. Re: Last Element Notation
I like either "fin" or "end", as they're both easy to type & are descriptive
rather than symbolic, which can help newbies understand what's meant.
Dan Moyer
----- Original Message -----
From: "Juergen Luethje" <j.lue at gmx.de>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Last Element Notation
>
>
> David wrote:
>
> > Robert Craig wrote:
> >
> >> Unless someone has a better idea, I think I'll go ahead
> >> with this idea of $ meaning "the index of the last element".
> >> e.g.
> >> s[1..$]
> >> s[1..$-1]
> >> s[$-2]
> >> etc.
> >
> > I agree that this is probably the best notation. There are shorter
notations
> > (for example, see Python), but they lack the clarity of the '$'
notation.
> >
> > The only real complaint is that it's another step toward the
Perlification of
> > the language. The 'end' token would be more clear:
> >
> > s[1..end]
> > s[1..end-1]
> > s[end-2]
> >
> > but I have difficulty convincing myself that this is much better,
especially
> > given that 'end' already has a distinct meaning in Euphoria. And the '$'
is
> > shorter and easy to see.
>
> How about using this, in order to prevent Perlification:
> s[1..fin]
> s[1..fin-1]
> s[fin-2]
>
> AFAIR 'fin' often appeared at the end of old movies.
>
> > Besides, If it were *true* Perlification, you'd have selected the '^'
token.
> >
> > -- David Cuny
>
> Regards,
> Juergen
>
> --
> /"\ ASCII ribbon campain | |\ _,,,---,,_
> \ / against HTML in | /,`.-'`' -. ;-;;,_
> X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
> / \ and unneeded MIME | '---''(_/--' `-'\_)
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
17. Re: Last Element Notation
Jim wrote:
> Juergen,
>
> I do like your ideas of using fin and last as keywords instead of $.
>
> The problem there is backwards compatibility.
Unfortunately, this is true.
I had the impression, that neither '$' nor 'end' was 100% convincing to
the community. And also nothing else has been found up to now, where all
say "Very great, that's it!". So I just wanted to throw some additional
ideas into the discussion.
> I have used last as a variable
> name in many files, so using that as a keyword might break things. fin as well
> (see, fin = File INput).
My hope was, that at least 'fin' is so uncommon, that it's rarely used.
Now I know better.
> Of course, thats a minor issue (is it really so hard to change all fin to
> fin_ and all last to last_ (or even fin___ and last___)?).
I don't know. I think it could be annoying. A poweful tool for searching
and replacing would be very helpful, though. For Windows, I can
recommend e.g. the program "InfoRapid Search & Replace"
http://www.inforapid.de/
(Freeware for privat use)
> Still, it may
> prove just enough to prevent the addition of a new keyword into the language.
>
> jbrown
Yes, I see. Thanks for your comments.
Best regards,
Juergen
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
18. Re: Last Element Notation
On Sat, Sep 20, 2003 at 09:56:22PM +0200, Juergen Luethje wrote:
Jim wrote:
> Juergen,
>
> I do like your ideas of using fin and last as keywords instead of $.
>
> The problem there is backwards compatibility.
Unfortunately, this is true.
I had the impression, that neither '$' nor 'end' was 100% convincing to
the community. And also nothing else has been found up to now, where all
say "Very great, that's it!". So I just wanted to throw some additional
ideas into the discussion.
Nothing wrong with that at all.
> I have used last as a variable
> name in many files, so using that as a keyword might break things. fin as well
> (see, fin = File INput).
My hope was, that at least 'fin' is so uncommon, that it's rarely used.
Now I know better.
Could try fin_ or fin__ or even fin__uncommon. These are likely to not be used
by any program. Really ugly tho.
Could even try _fin or _end, which (since they start with an underscore) are
guarrenteed to not be used. But alas, still ugly.
> Of course, thats a minor issue (is it really so hard to change all fin to
> fin_ and all last to last_ (or even fin___ and last___)?).
I don't know. I think it could be annoying. A poweful tool for searching
and replacing would be very helpful, though. For Windows, I can
recommend e.g. the program "InfoRapid Search & Replace"
http://www.inforapid.de/
(Freeware for privat use)
Of course us Linux and FreeBSD users have had such a powerful tool for a long
time. :D (In case your wondering, its /bin/sed.)
> Still, it may
> prove just enough to prevent the addition of a new keyword into the language.
>
> jbrown
Yes, I see. Thanks for your comments.
Thank you for yours.
Best regards,
Juergen
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
TOPICA - Start your own email discussion group. FREE!
--
"May peace find its way through the heavens to the world of men and women
before the fires of the damned consume them." - Someone
