1. Last Element Reference
Robert,
If I may, I'd like to supply a requirements document for the proposed
enhancement to Euphoria.
Title: Last Element Reference
Functional Requirement:
To enable a coder to reference the last element in a sequence, within
slice specifications and element references, without having to explicitly
name the sequence itself.
Benefits:
* Reduce the amount of typing.
* Reduce the possibility of misspelling a identifier.
* Improve legibility by reducing the number of characters to read.
* Improve interpreter performance by having less tokens to process.
Costs:
* If using a new syntax symbol, it will reduce the number of available
symbols for future use.
Technical Specification:
I suggest that the character '$' be used as a shorthand for
"length(<seq>)" when '$' appears inside a slice specification or inside an
element reference. And that the sequence it refers to is the same one that
the slice and element reference is using.
Examples:
sequence X
X = {"ant", "bear", "cat", "dog", "elephant"}
? X[$] --> "elephant"
? X[$][$] --> 't'
? X[3 .. $] --> {"cat", "dog", "elephant"}
? X[3 .. $-1] --> {"cat", "dog"}
? X[$-1..$] --> {"dog", "elephant"}
? X[$][3..$] --> "ephant"
? X[$][$-3..$] --> "hant"
? X[2][$] --> 'r'
? X[1 .. $-1] --> {"ant", "bear", "cat", "dog"}
? X[1 .. floor($/2)] --> {"ant", "bear"}
? X[floor($/2)+1 .. $] --> {"cat", "dog", "elephant"}
--
cheers,
Derek Parnell
2. Re: Last Element Reference
Derek Parnell wrote:
> If I may, I'd like to supply a requirements document for the proposed
> enhancement to Euphoria.
>
> Title: Last Element Reference
>
> Functional Requirement:
> To enable a coder to reference the last element in a sequence, within
> slice specifications and element references, without having to
> explicitly name the sequence itself.
>
> Benefits:
> * Reduce the amount of typing.
> * Reduce the possibility of misspelling a identifier.
> * Improve legibility by reducing the number of characters to read.
> * Improve interpreter performance by having less tokens to process.
>
> Costs:
> * If using a new syntax symbol, it will reduce the number of available
> symbols for future use.
>
> Technical Specification:
> I suggest that the character '$' be used as a shorthand for
> "length(<seq>)" when '$' appears inside a slice specification or inside
> an element reference. And that the sequence it refers to is the same one
> that the slice and element reference is using.
>
> Examples:
>
> sequence X
>
> X = {"ant", "bear", "cat", "dog", "elephant"}
>
> ? X[$] --> "elephant"
> ? X[$][$] --> 't'
> ? X[3 .. $] --> {"cat", "dog", "elephant"}
> ? X[3 .. $-1] --> {"cat", "dog"}
> ? X[$-1..$] --> {"dog", "elephant"}
> ? X[$][3..$] --> "ephant"
> ? X[$][$-3..$] --> "hant"
> ? X[2][$] --> 'r'
> ? X[1 .. $-1] --> {"ant", "bear", "cat", "dog"}
> ? X[1 .. floor($/2)] --> {"ant", "bear"}
> ? X[floor($/2)+1 .. $] --> {"cat", "dog", "elephant"}
Yes. That's exactly what I was thinking.
There are some weird cases too, like:
x[y[$]..$] -- $ refers to the immediately enclosing brackets
x[$ * $ - foo($)] -- $ could be used anywhere, in any way
-- inside the brackets
$ would be a kind of very localized constant
with a scope from [ to ]. It's value would be
the length of the sequence being subscripted or sliced.
Pete Lomax wrote:
> 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 find negative subscripts to be a bit less clear.
Plus I'd like to continue to be able to catch all
negative numbers as bad subscripts.
> "end" may be a more readable alternative to $.
> When "end" is between [] should be no major parsing problem?
"end" could be parsed easily enough using the RDS parser,
but I think it would be visually confusing for a person
reading the code, especially a beginner. He might
confuse it with "end if", "end for", "end procedure" etc.,
or he might think "end" was a variable, and might wonder
where it was assigned or declared.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Last Element Reference
On Thu, 18 Sep 2003 20:59:43 -0400, Robert Craig
<rds at RapidEuphoria.com> wrote:
>I find negative subscripts to be a bit less clear.
Oh well.
>Plus I'd like to continue to be able to catch all
>negative numbers as bad subscripts.
I worried about that too, at first, but then I realised that [0] is
still going to catch most errors on the way down, and naturally
anything less than -length(x) should also trap.
Regards,
Pete
4. Re: Last Element Reference
On Thu, 18 Sep 2003 20:59:43 -0400 (09/19/03 10:59:43)
, Robert Craig <rds at RapidEuphoria.com> wrote:
[snip]
>
> $ would be a kind of very localized constant
> with a scope from [ to ]. It's value would be
> the length of the sequence being subscripted or sliced.
>
Excellent. That will do just nicely.
--
cheers,
Derek Parnell
5. Re: Last Element Reference
Hello Derek, Hello Rob,
How about '|' instead of '$' ?
> sequence X
>
> X = {"ant", "bear", "cat", "dog", "elephant"}
>
> ? X[|] --> "elephant"
> ? X[|][|] --> 't'
> ? X[3 .. |] --> {"cat", "dog", "elephant"}
> ? X[3 .. |-1] --> {"cat", "dog"}
> ? X[|-1..|] --> {"dog", "elephant"}
> ? X[|][3..|] --> "ephant"
> ? X[|][|-3..|] --> "hant"
> ? X[2][|] --> 'r'
> ? X[1 .. |-1] --> {"ant", "bear", "cat", "dog"}
> ? X[1 .. floor(|/2)] --> {"ant", "bear"}
> ? X[floor(|/2)+1 .. |] --> {"cat", "dog", "elephant"}
'|' is just a sign for border, bound, limit,
edge, brink and other ends.
'$' is dollar, nothing more.
Regards,
Igor Kachan
kinz at peterlink.ru
6. Re: Last Element Reference
Again Hello Rob, Hello Derek,
----------
> From: Igor Kachan <kinz at peterlink.ru>
> Subject: Re: Last Element Reference
>
> Hello Derek, Hello Rob,
>
> How about '|' instead of '$' ?
>
> > sequence X
> >
> > X = {"ant", "bear", "cat", "dog", "elephant"}
> >
> > ? X[|] --> "elephant"
> > ? X[|][|] --> 't'
> > ? X[3 .. |] --> {"cat", "dog", "elephant"}
> > ? X[3 .. |-1] --> {"cat", "dog"}
> > ? X[|-1..|] --> {"dog", "elephant"}
> > ? X[|][3..|] --> "ephant"
> > ? X[|][|-3..|] --> "hant"
> > ? X[2][|] --> 'r'
> > ? X[1 .. |-1] --> {"ant", "bear", "cat", "dog"}
> > ? X[1 .. floor(|/2)] --> {"ant", "bear"}
> > ? X[floor(|/2)+1 .. |] --> {"cat", "dog", "elephant"}
>
> '|' is just a sign for border, bound, limit,
> edge, brink and other ends.
>
> '$' is dollar, nothing more.
Another way may be:
? X[3..-1|] --> {"cat", "dog"}
? X[-1|..|] --> {"dog", "elephant"}
? X[|][-3|..|] --> "hant"
The 'floor' command is extra one here, so:
? X[1../2|] --> {"ant", "bear"}
The '+' and '*' commands are impossible
with the '|' constant, so this reverse notation may
be very clear and handy for this special case, I think.
This '|' sign is similar to 'l' letter --
good mnemonic for the 'last' word.
Color syntax may be handy to differ 'l' and '|'.
'$' is not so good, I think now.
Regards,
Igor Kachan
kinz at peterlink.ru
7. Re: Last Element Reference
Hello Al,
[snipped]
>Hello Igor,
>Surely you jest 
>"|" has got to be the worst choice.
>It looks too much like other things.
Just use red blinking color for this
special sign of a some future Euphoria
syntax, then it will be as a stop signal 
>In some fonts it may be very hard to tell the
>difference between "|" and the capital i and
>lower case L.
Good, it is the 'Last' element, why not to be
similar the lower case L ?
>Also, it's used in mathematics to indicate
>absolute value:
>x=|a| --"take the absolute value of 'a' "
>so it functions almost the same as parenthesis,
>brackets and braces, to enclose something else.
Good, this is a vertical line with the top and
bottom limits of integral, do you see -- limits?
L again.
>This means it looks too strange when inserted
>between [ and ] like this:
>s=s[|]
Imagine, this line is red and blinking!
Cooollll ! Do you see 'llll'?
L again. Last element !
>To a person familiar with math, this looks incomplete.
>Can you tell me it's clearer then
>s=s[$] ?
When I see $ I think about the next month
payment for my apartment, not about math,
programming and Euphoria %-(
>I dont think so.
Think, think, please ....
I hate basic and pascal now for
these perpetual
%%%%% $$$$$$ @@@@@@ ^^^^^^^ !!!!!!!
##### .....
!@#$%^&* -- do you know this word ?
I think, this word is invention of
one basic/pascal/c programmer.
>On the other hand, the "$" signs only other use
>is with money (dollars) where it's context is
>very easily distinguished from a sequence reference,
>plus it dosnt look much like anything else except
>the capital letter "S", but yet not close enough to
>be confused too easily.
Red blinking ...
Or let us define this letter:
last element ##
last element @@
last element $$
Why not?
Interpreter is just about 100K.
Let us add 100K.
>Even more readable but harder to type would be the
>double dollar sign:
>s=s[$$]
>How about:
>s=s[ch]
Why not?
(I have corrected your letter just
for Topica).
But Rob doesn't want unlimited alphabet
for the RDS' full featured Euphoria
>
>Take care for now,
>Al
Regards,
Igor Kachan
kinz at peterlink.ru
8. Re: Last Element Reference
> How about '|' instead of '$' ?
>
> > sequence X
> >
> > X = {"ant", "bear", "cat", "dog", "elephant"}
> >
> > ? X[|] --> "elephant"
> > ? X[|][|] --> 't'
> > ? X[3 .. |] --> {"cat", "dog", "elephant"}
> > ? X[3 .. |-1] --> {"cat", "dog"}
> > ? X[|-1..|] --> {"dog", "elephant"}
> > ? X[|][3..|] --> "ephant"
> > ? X[|][|-3..|] --> "hant"
> > ? X[2][|] --> 'r'
> > ? X[1 .. |-1] --> {"ant", "bear", "cat", "dog"}
> > ? X[1 .. floor(|/2)] --> {"ant", "bear"}
> > ? X[floor(|/2)+1 .. |] --> {"cat", "dog", "elephant"}
>
> '|' is just a sign for border, bound, limit,
> edge, brink and other ends.
>
> '$' is dollar, nothing more.
Personally, '|' blends in too well with [], "[|]" is a lot of vertical
lines, and it may be difficult to find a syntax error if one should enter
two vertical lines "[||]" at least it would for me, since most of my
programming occours after 9 pm :) and I thought the vertical line ( '|' )
in C was OR not end? (i'm not a C programmer, i may be wrong)
~Greg
9. Re: Last Element Reference
Igor wrote:
> Hello Al,
>
> [snipped]
>
>> Hello Igor,
>
>> Surely you jest
>
>> "|" has got to be the worst choice.
>> It looks too much like other things.
>
> Just use red blinking color for this
> special sign of a some future Euphoria
> syntax, then it will be as a stop signal
Syntax highlighting is a very useful feature of good editors used for
programming, but thinking about readability of a language, one should
not rely to much on it.
I want Euphoria programs to be easily readable not only in my editor,
but also in my e-mail programm, in the Topica web-interface etc.
Maxbe '$' is not the best choice, but I personally would not like to see
'|' as symbol for 'length(x)'.
<snip>
Regards,
Juergen
--
/"\ ASCII ribbon campain |
\ / against HTML in | This message has been ROT-13 encrypted
X e-mail and news, | twice for higher security.
/ \ and unneeded MIME |
10. Re: Last Element Reference
I don't want negative indexing. I use to like the idea. But it is too
easy for certain bugs to creep in and certain errors to go
undetected for a long time.
Lucius L. Hilley III
11. Re: Last Element Reference
On Fri, 19 Sep 2003 22:27:52 -0400, Lucius Hilley
<l3euphoria at bellsouth.net> wrote:
>
>
>I don't want negative indexing. I use to like the idea. But it is too
>easy for certain bugs to creep in and certain errors to go
>undetected for a long time.
Care to back that up with any facts or examples?
Pete
12. Re: Last Element Reference
> From: Al Getz <Xaxo at aol.com>
> Subject: RE: Last Element Reference
>
> Hi again Igor,
Hi Al,
> Surely you jest to the second power? )
No, I just do not like the '$' sign as
a name for the last element of given sequence ;)
Yes, it has some meaning, S - sequence - and a
vertical line(s) as a sign of an end,
but dollar is dollar, nothing more.
There is the special character - vertical line.
And there may be the special key word in Euphoria,
say, 'eos' - end of sequence, or 'les' - last element
of sequence, or something else.
Or just old good EU's 'end'. Why not, really?
> I agree with a lot of what you say, but i just dont like
> the idea of using "|" as the end-of-sequence reference char.
But I do like this idea because of some senses
of the '|' sign - similar to 'l'
(the first letter of the 'last' word),
may mark the ends of different nature,
used as math symbol for limits of integral,
so to say, it is the sign for the end of all ends,
last line.
> Do you honestly think that a single character is worth
> linking a specific editor or editor function for the sole
> purpose of making it blink?
This is a question of taste. But customised
blinking may be useful for some key words
in some cases.
For example, as a powerful reminder.
In my version of ed editor, which I use
with unlimited alphabet interpreter,
the error message is bright white and
blinking.
> Really, think about it.
> Yes, in the trace screen Rob could make it blink, fur sure,
> but what about in the myriad of editors out there that dont?
If you do not want blinking then do not use it.
If you want to see some thing without any doubt
then make it blinking.
> You certainly have some good ideas though, dont get me wrong.
Thanks.
> I never thought of making it blink myself, but then i also
> thought that sort of thing went out with the console editors?
I prefer the console editors for my work.
I use ed, edit.com, far - this is the
console command shell for Windows, the excellent
advanced functional copy of the Norton Commander,
with ftp, local net and many other very powerful
features.
> Perhaps a certain color...but what i found out in just the last
> few days is that there still isnt a set color scheme for
> certain things, so it's better not to depend on things like
> that for syntax but rather go by the older rules of using
> something that isnt related to it yet--unless of course
> you have complete control over the color scheme--which none
> of us does in this case.
> Also, you might recall a similar syntax ($) used in asm
> (although not exactly the same).
>
> It's really not a bad idea if you give it a chance.
>
> When it comes time to debug your program, i bet you will
> be happy that you can psychologically understand the character
> "$" faster then you can "|" because it doesnt look like
> a lower case l or the numeral '1'.
Oh, yes, the '$' sign is very well visible. ;)
One can sleep and see $$$$$$$$, say, M$.
> As for your saying that it SHOULD look like an 'L' because
> it means the 'last' character, that has nothing to do with it.
> The main reason is because you might also choose a variable
> named 'l'.
> How fast can you read this:
>
> s=s[1..l]&s[2..|]&y[|-1..9-|]
>
> Now try this:
>
> s=s[1..$]&s[2..$]&y[$-1..9-$]
>
> Then try this:
>
> s=s[1..$$]&s[2..$$]&y[$$-1..9-$$]
>
> You comments now?
Too many $$$$$$$$, I want to grab them all for myself ;P
> I think the double $ sign is faster to read, but ill
> accept the single $ sign too, and after all, it's one
> less char to type.
>
> 'end' bites, just like 'fin' for reason stated in
> other posts.
Yes, but the '|' sign is under your and my fingers
near the Enter key.
> So far my choices are, in order of pref:
>
> [1] "$$"
> [2] "$"
> [3] (none)
> [$$+1000000] "|"
>
>
> I would like to hear your comments...
Al, I prefer to do the following things just now:
--- code
atom EoS
type sequence_with_EoS(object a)
if sequence(a) then
EoS = length(a)
if EoS then return 1
else return 0 end if
else return 0 end if
end type
sequence_with_EoS XxXx_EoS
XxXx_EoS = "Euphoria is clear programming language!"
puts(1, XxXx_EoS)
? EoS
---- end of code
Then earn $1000000 of MicroMoney :)
Do you see, standard Euphoria wants more
available characters in its alphabet
and loadable key words and special characters ?
> Take care for now,
> Al
Good luck with $$$$$$$$!
Regards,
Igor Kachan
kinz at peterlink.ru
-----------------
> Igor Kachan wrote:
> >
> >
> > Hello Al,
> >
> > [snipped]
> >
> > >Hello Igor,
> >
> > >Surely you jest
> >
> > >"|" has got to be the worst choice.
> > >It looks too much like other things.
> >
> > Just use red blinking color for this
> > special sign of a some future Euphoria
> > syntax, then it will be as a stop signal
> >
> > >In some fonts it may be very hard to tell the
> > >difference between "|" and the capital i and
> > >lower case L.
> >
> > Good, it is the 'Last' element, why not to be
> > similar the lower case L ?
> >
> > >Also, it's used in mathematics to indicate
> > >absolute value:
> > >x=|a| --"take the absolute value of 'a' "
> > >so it functions almost the same as parenthesis,
> > >brackets and braces, to enclose something else.
> >
> > Good, this is a vertical line with the top and
> > bottom limits of integral, do you see -- limits?
> > L again.
> >
> > >This means it looks too strange when inserted
> > >between [ and ] like this:
> > >s=s[|]
> >
> > Imagine, this line is red and blinking!
> >
> > Cooollll ! Do you see 'llll'?
> > L again. Last element !
> >
> > >To a person familiar with math, this looks incomplete.
> > >Can you tell me it's clearer then
> > >s=s[$] ?
> >
> > When I see $ I think about the next month
> > payment for my apartment, not about math,
> > programming and Euphoria %-(
> >
> > >I dont think so.
> >
> > Think, think, please ....
> >
> > I hate basic and pascal now for
> > these perpetual
> > %%%%% $$$$$$ @@@@@@ ^^^^^^^ !!!!!!!
> > ##### .....
> >
> > !@#$%^&* -- do you know this word ?
> >
> > I think, this word is invention of
> > one basic/pascal/c programmer.
> >
> > >On the other hand, the "$" signs only other use
> > >is with money (dollars) where it's context is
> > >very easily distinguished from a sequence reference,
> > >plus it dosnt look much like anything else except
> > >the capital letter "S", but yet not close enough to
> > >be confused too easily.
> >
> > Red blinking ...
> >
> > Or let us define this letter:
> >
> > last element ##
> >
> > last element @@
> >
> > last element $$
> >
> > Why not?
> >
> > Interpreter is just about 100K.
> > Let us add 100K.
> >
> > >Even more readable but harder to type would be the
> > >double dollar sign:
> >
> > >s=s[$$]
> >
> > >How about:
> >
> > >s=s[ch]
> >
> > Why not?
> >
> > (I have corrected your letter just
<snip>
13. Re: Last Element Reference
- Posted by eugtk at yahoo.com
Sep 20, 2003
To all who are arguing about what character should be
used:
Shut Up!
Rob has agreed to make this most useful and often
requested change. Have you forgotten how difficult
it has been to get anything added to Euphoria?!?
I personally don't care if it's $, ^, ~ , @ or |,
or fin, fini, end, last, or whatever, as long
as it gets done. Arguing incessantly about piddling
details is counterproductive, and likely to only annoy
Rob and make it even harder to get improvements made
in the future.
Irv
14. Re: Last Element Reference
- Posted by jzeitlin at cloud9.net
Sep 20, 2003
On Fri, 19 Sep 2003 21:30:35 -0700, Al Getz <Xaxo at aol.com> wrote:
[corrected top-posting]
>Lucius Hilley wrote:
>> I don't want negative indexing. I use to like the idea. But it is too
>> easy for certain bugs to creep in and certain errors to go
>> undetected for a long time.
>Ok, then i guess you will never want to do:
>s="MyFile.exw"
>Name=s[1..6]
>Ext=s[$-3..$]
>in which you have to use a negative '3' anyway.
This is not using negative indexing; this is using a calculated index. Under
the proposed
format, "$" used as a subscript will always be a non-negative number (I suppose
it could
conceivably be zero), and if $-n is less than zero for a particular value of n,
you would
get an error from Euphoria (as you do now if you try to use a negative subscript
on a
sequence).
--
Jeff Zeitlin
jzeitlin at cyburban.com
15. Re: Last Element Reference
Lucius wrote:
> I don't want negative indexing. I use to like the idea. But it is too
> easy for certain bugs to creep in and certain errors to go
> undetected for a long time.
At the moment, I can't imagine a piece of code where something like that
happens. Can you give an example, please?
Regards,
Juergen
--
The difference between men and boys
is the price of their toys.
16. Re: Last Element Reference
- Posted by jzeitlin at cloud9.net
Sep 20, 2003
On Sat, 20 Sep 2003 08:12:04 -0700, Al Getz <Xaxo at aol.com> wrote:
>jzeitlin at cloud9.net wrote:
>> This is not using negative indexing; this is using a calculated index.
>> Under the proposed
>> format, "$" used as a subscript will always be a non-negative number (I
>> suppose it could
>> conceivably be zero), and if $-n is less than zero for a particular
>> value of n, you would
>> get an error from Euphoria (as you do now if you try to use a negative
>> subscript on a
>> sequence).
>All i meant was that using a negative index is 'almost' the same
>as using "$" minus some number. Let's compare two examples.
>[1] using $
>s="MyFile.exw"
>Name=s[1..6]
>Ext=s[$-3..$]
>[2] using (-) indexing
>s="MyFile.exw"
>Name=s[1..6]
>Ext=s[-4..-1]
>This is why i thought Petes idea was good.
But it does, as was previously indicated, remove the possibility of using a
check for
negative subscript as a flaggable error. This might not be a problem if
sequences were
internally (to the Euphoria interpreter) managed as association lists, but if
they're
managed as arrays (as seems likely), you're complicating things pretty much
needlessly.
On the other hand, using "s[$]" isn't any more complicated from the
interpreter's (and
Rob's, as the writer of the interpreter) point of view than would be using the
expression
s[length(s)] - in fact, the _translator_ could (and probably would) generate
_exactly_ the
same code for both.
>The only thing i dont like is that the "-1"
>after the two dots looks a little strange there.
I'm ignoring esthetics for now. I'm interested in functionality and internal
consistency.
>What about both at the same time?
>[3] using (-) indexing AND "$" for the end
>s="MyFile.exw"
>Name=s[1..6]
>Ext=s[-4..$]
>This looks pretty clear, but it involves more of a change
>to the language then just adding "$" to it.
Indeed it does - and it still possesses the disadvantages of allowing negative
subscripting. What's more, this idea requires the maintenance of _two_ internal
pseudoconstants for each sequence, its length (for the use of $), and
_one_more_than_its_length_, to support the negative subscripting, as the two
expressions
s[$]
s[-1]
would necessarily return the same (last) element of the sequence. It would be
simpler -
for Rob, as the author of the language and it's normative interpreter - to
maintain only
the $ symbolic pseudoconstant, as all that would need be done is (essentially,
pseudocode
description)
if token-encountered = "$" AND expression-context = sequence-subscript THEN
return
sequence-length
(with appropriate use of variables to indicate _which_ sequence the current
context is
referring to).
And for you and me, it doesn't add any real complexity to the language; it's
what's often
called "syntactic sugar", making "$" exactly equivalent to "length()" as a
sequence
subscript.
--
Jeff Zeitlin
jzeitlin at cyburban.com
17. Re: Last Element Reference
On Sat, 20 Sep 2003 11:54:49 -0400, jzeitlin at cloud9.net wrote:
>>All i meant was that using a negative index is 'almost' the same
>>as using "$" minus some number. Let's compare two examples.
>
>>[1] using $
>>s=3D"MyFile.exw"
>>Name=3Ds[1..6]
>>Ext=3Ds[$-3..$]
>
>>[2] using (-) indexing
>>s=3D"MyFile.exw"
>>Name=3Ds[1..6]
>>Ext=3Ds[-4..-1]
>
>>This is why i thought Petes idea was good.
>
>But it does, as was previously indicated, remove the possibility of =
using a check for
>negative subscript as a flaggable error.
No. What it does is double the number of values that can be used to
access an existing element of a sequence, nothing as drastic as
"remove the possibility".=20
Given that you can currently index a sequence of length ten with ten
values, possibly wrongly, changing that to being able to index it with
twenty values, possibly wrongly, does not seem all that scary to me.
Unfortunately, no-one has yet come up with a situation or code snippet
which shows a bug that mirror indexes never trap.
I would also argue that probably more than 9 out of 10 index errors
are out-by-one, which lands nicely on [0] and still triggers an error.
Strange I haven't seen anyone come up with the argument that they
would have to test their software more thoroughly. )
> This might not be a problem if sequences were
>internally (to the Euphoria interpreter) managed as association lists, =
but if they're
>managed as arrays (as seems likely), you're complicating things pretty =
much needlessly.
Rob, from your knowledge of the internals of Euphoria, is my assertion
wrong that the required change would be:
if a<0 then a+=3Dlength()+1
-- normal bounds checking
I'm just interested, feel free to say yes and not do it
>On the other hand, using "s[$]" isn't any more complicated from the =
interpreter's (and
>Rob's, as the writer of the interpreter) point of view than would be =
using the expression
>s[length(s)] - in fact, the _translator_ could (and probably would) =
generate _exactly_ the
>same code for both.
No. The interpreter has to keep track of what the $ applies to,
whereas length() is explicitly told this.
>
<snip>
>if token-encountered =3D "$" AND expression-context =3D =
sequence-subscript THEN return
>sequence-length
It doesn't happen very often, but which sequence length?
a[$][b[$]..$]
I find the rareness aspect slightly worrying because it makes it so
hard to properly test. Guess I'm glad it's Rob doing it.
>
>(with appropriate use of variables to indicate _which_ sequence the =
current context is
>referring to).
I agree, far more complicated than my suggested approach.
If Rob really doesn't want this (and I think I can assure you he
doesn't), then fine. I'll live.
If you don't want it then fine, just say so, but unfortunately for all
those listening in, it's in my nature, with something I want, to carry
on *discussing* this if you say something I think is wrong
Pete
18. Re: Last Element Reference
Irv wrote:
> To all who are arguing about what character should be
> used:
>
> Shut Up!
>
> Rob has agreed to make this most useful and often
> requested change. Have you forgotten how difficult
> it has been to get anything added to Euphoria?!?
Rob wrote on 17 Sep 2003:
<quote>
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.
<unquote>
I admit that my knowledge of the English language is limited, but for me
these words sound more like a request for discussion, than a request for
being quiet.
> I personally don't care if it's $, ^, ~ , @ or |,
> or fin, fini, end, last, or whatever, as long
> as it gets done.
That's fine, but I'm sure you know, that other poeople might have other
opinions.
> Arguing incessantly about piddling
> details is counterproductive,
You are missing the point.
What you call "arguing incessantly about piddling details" actually was
some brainstorming and discussion, in order to collect the PROs and CONs
of some suggestions. This is a discussion list, no?
The things discussed have got to do with readability, consistency,
subscript checking etc.
> and likely to only annoy
> Rob and make it even harder to get improvements made
> in the future.
I'm pretty sure, that Rob can speak for himself, and I hope and
believe, that he will tell the community, if something is actually
annoying him here.
Regards,
Juergen
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
19. Re: Last Element Reference
----- Original Message -----
From: "Juergen Luethje" <j.lue at gmx.de>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Last Element Reference
>
>
> Lucius wrote:
>
> > I don't want negative indexing. I use to like the idea. But it is too
> > easy for certain bugs to creep in and certain errors to go
> > undetected for a long time.
>
> At the moment, I can't imagine a piece of code where something like that
> happens. Can you give an example, please?
>
-- Build list.
for i = 1 to length(s) do
rid = routine_id(funcA(s[i]))
if rid > length(ridlist) then
ridlist &= repeat(-1, rid - length(ridlist))
end if
ridlist[rid] = DefaultValues
end for
. . . then later in program
rid = routine_id(funcA(x))
ridlist[rid] = UpdatedValues
. . .
Okay, so here we have a program that stores some parameter values that are
indexed via the Routine_ID that they apply to. This works fine until we supply
the funcA() routine an unknown routine name. In that case it returns a -1. Now if
negative indexing were allowed, this would update the LAST parameter set rather
than causing an exception. Yes, its a bug and poor programming practice, but it
might take awhile to detect and to find.
Although this is contrived, it is a realistic scenario.
A similar situation could be set up for file handles returned by open() as that
uses -1 to signal an error too.
--
Derek
Ok, so here is a piece of code that is supposed to do something with a element
of a sequence, but we don't know where abouts that portion starts until run time.
20. Re: Last Element Reference
Hi Irv,
> To all who are arguing about what character should be
> used:
>
> Shut Up!
Yes, sir!
> Rob has agreed to make this most useful and often
> requested change. Have you forgotten how difficult
> it has been to get anything added to Euphoria?!?
Very good, sir!
> I personally don't care if it's $, ^, ~ , @ or |,
> or fin, fini, end, last, or whatever, as long
> as it gets done.
Me too, sir!
> Arguing incessantly about piddling
> details is counterproductive,
But, sir, there is just devil just in pidding details, sir!
And now, sir, we are talking just about '$' -- devil from devils, sir!
>and likely to only annoy Rob and make it even
>harder to get improvements made in the future.
He-he, sir, Rob is well known as a very regular and wise guy, sir!
I can not agree, sir, shoot me, sir !
Rob just do not want any, excuse me, sir, crap inside
the best programming language, sir!
> Irv
Regards,
Igor Kachan
kinz at peterlink.ru
21. Re: Last Element Reference
- Posted by jzeitlin at cloud9.net
Sep 21, 2003
On Sat, 20 Sep 2003 17:02:14 -0700, Al Getz <Xaxo at aol.com> wrote:
>jzeitlin at cloud9.net wrote:
[deleted for bandwidth]
>> But it does, as was previously indicated, remove the possibility of
>> using a check for
>> negative subscript as a flaggable error. This might not be a problem if
>> sequences were
>> internally (to the Euphoria interpreter) managed as association lists,
>> but if they're
>> managed as arrays (as seems likely), you're complicating things pretty
>> much needlessly.
>> On the other hand, using "s[$]" isn't any more complicated from the
>> interpreter's (and
>> Rob's, as the writer of the interpreter) point of view than would be
>> using the expression
>> s[length(s)] - in fact, the _translator_ could (and probably would)
>> generate _exactly_ the
>> same code for both.
>So you're telling me you dont have to check for negative
>subscripts here:
>s={1}
>s=s[$-1000,$-2000]
No, I'm NOT. You absolutely have to check for negative subscripting, and Rob
has already
included this code in the Euphoria interpreter - you will get an error if you
try to take
s[-1].
Your proposal, of allowing negative subscripts without the $, requires
significant
internal programmatic change to the interpreter - and removes the ability to
flag an error
if a negative subscript is encountered. Because a negative subscript actually
would mean
something legitimate.
>The only shortcut it *really* gives is when checking "$" alone:
>s=s[1..$]
>but anytime something is subtracted from $ you *STILL* have
>to check for minus subscripts.
Yes, exactly - and the result of subtracting from $ still MUST be non-negative
(and may in
fact have to be positive; I don't recall offhand whether 0 is a valid subscript)
- or
Euphoria will signal an error condition. Your proposal for 'bare' negative
subscripts
_breaks_ that check. Or rather, makes it impossible to use that check.
>> >The only thing i dont like is that the "-1"
>> >after the two dots looks a little strange there.
>> I'm ignoring esthetics for now. I'm interested in functionality and
>> internal consistency.
>It's not a simple matter of esthetics. It's a matter of
>psychology and the stress it produces. If you have to
>pay more attention to detail, it creates more stress.
>The more stress, the more energy the brain uses.
>The more energy the brain uses, the slower you debug code.
I have _never_ seen such a bogus argument in my life. Not even when it was
_clear_ that
someone was trolling.
Programming is INHERENTLY about paying attention to detail. If you don't pay
attention to
detail, and get everything exactly right, how can you be sure that the program
is going to
do what you want it to? Hell, even _with_ that level of paying attention to
detail,
programs still have bugs in them - and you want to introduce constructs that
will make
bugs _less_ detectable? Programs can't do anything except what you tell them to
- and
they can't guess, either, and even if they could, what would you - or your users
- do if
the computer guessed _wrong_? Even those programs that act like you don't have
to be
precise are only acting within their programming, and there are definite limits
to the
imprecision available.
>> >What about both at the same time?
>> >[3] using (-) indexing AND "$" for the end
>> >s="MyFile.exw"
>> >Name=s[1..6]
>> >Ext=s[-4..$]
>> >This looks pretty clear, but it involves more of a change
>> >to the language then just adding "$" to it.
>> Indeed it does - and it still possesses the disadvantages of allowing
>> negative
>> subscripting. What's more, this idea requires the maintenance of _two_
>> internal
>> pseudoconstants for each sequence, its length (for the use of $), and
>> _one_more_than_its_length_, to support the negative subscripting, as the
>> two expressions
>> s[$]
>> s[-1]
>> would necessarily return the same (last) element of the sequence. It
>> would be simpler -
>> for Rob, as the author of the language and it's normative interpreter -
>> to maintain only
>> the $ symbolic pseudoconstant, as all that would need be done is
>> (essentially, pseudocode
>> description)
>> if token-encountered = "$" AND expression-context = sequence-subscript
>> THEN return
>> sequence-length
>> (with appropriate use of variables to indicate _which_ sequence the
>> current context is
>> referring to).
>> And for you and me, it doesn't add any real complexity to the language;
>> it's what's often
>> called "syntactic sugar", making "$" exactly equivalent to "length()" as
>> a sequence
>> subscript.
>It doesnt really matter to me what it's often called
>It's also ok with me to use $, i was just bringing up some
>points about other possibilities.
I've been programming - in almost any language at a higher level than assembly -
for the
last 25 years or so, and my experience is that the more difficult you make it to
detect
errors, the less detectable the errors are, and the more difficult it is to
write correct
programs. I've used languages like BASIC/Pascal/Euphoria, languages like C/C++,
languages
like COBOL, languages like LISP/Scheme, languages like APL, languages like
SNOBOL, and so
on, and there _are_ certain constant attributes of all of those languages - and
imprecision and internal inconsistency isn't one of them. Please stop trying to
defend
the indefensible. Currently, I am unaware of _any_ language that allows
negative
subscripts on arrays without special - and expensive, in terms of machine
resources -
processing. My understanding is that Rob designed Euphoria to be _inexpensive_
in terms
of machine resources - less expensive than almost any extant third-generation
language -
while allowing the flexibility, capability, and ease of coding of most if not
all of those
third-generation languages (Rob, please correct me if I'm in error on that
understanding).
The $ idea as presented is in keeping with that ideal. Negative subscripting is
not.
>Your mind is closed because you heard the phrase
>"negative subscripts cant be detected easily"
>and you think it applies across the board without
>any question.
And please do not resort to ad hominem attacks when others with experience
refuse to
acknowledge your invalid views as valid.
--
Jeff Zeitlin
jzeitlin at cyburban.com
22. Re: Last Element Reference
- Posted by kbochert at copper.net
Sep 21, 2003
On 20 Sep 2003 at 20:35, jzeitlin at cloud9.net wrote:
>
>
> On Sat, 20 Sep 2003 17:02:14 -0700, Al Getz <Xaxo at aol.com> wrote:
>
> >jzeitlin at cloud9.net wrote:
>
> [deleted for bandwidth]
>
> >So you're telling me you dont have to check for negative
> >subscripts here:
> >s={1}
> >s=s[$-1000,$-2000]
>
> No, I'm NOT. You absolutely have to check for negative subscripting, and Rob
> has already
> included this code in the Euphoria interpreter - you will get an error if you
> try to take
> s[-1].
>
> Your proposal, of allowing negative subscripts without the $, requires
> significant
> internal programmatic change to the interpreter -
Sorry, no.
s[3..$-1]
and
s[3..length(s)-1]
and
s[3..-2]
are exactly the same thing expressed with different characters.
The final form is the easiest of the three for the interpreter (2 lines of C in
Bach).
>and removes the ability to flag an error
> if a negative subscript is encountered. Because a negative subscript actually
> would mean
> something legitimate.
>
No reduction of error checking occurs. In both cases, the index is checked
against the bounds of the sequence. The only difference is where the
index calculation occurs, and in fact the 'negative index' is superior in that
the "length(s)-x" occurs in compiled C code instead of interpreted Euphoria.
Karl Bochert
23. Re: Last Element Reference
On Sat, Sep 20, 2003 at 11:54:49AM -0400, jzeitlin at cloud9.net wrote:
>
>
> On Sat, 20 Sep 2003 08:12:04 -0700, Al Getz <Xaxo at aol.com> wrote:
>
> >jzeitlin at cloud9.net wrote:
>
> >> This is not using negative indexing; this is using a calculated index.
> >> Under the proposed
> >> format, "$" used as a subscript will always be a non-negative number (I
> >> suppose it could
> >> conceivably be zero), and if $-n is less than zero for a particular
> >> value of n, you would
> >> get an error from Euphoria (as you do now if you try to use a negative
> >> subscript on a
> >> sequence).
>
>
> >All i meant was that using a negative index is 'almost' the same
> >as using "$" minus some number. Let's compare two examples.
>
> >[1] using $
> >s="MyFile.exw"
> >Name=s[1..6]
> >Ext=s[$-3..$]
>
> >[2] using (-) indexing
> >s="MyFile.exw"
> >Name=s[1..6]
> >Ext=s[-4..-1]
>
> >This is why i thought Petes idea was good.
>
> But it does, as was previously indicated, remove the possibility of using a
> check for
> negative subscript as a flaggable error.
Well, not all negative subscripts, just those that are in the range
-1..-length(s),
anything less than -length(s) would still be flagged as an error.
> This might not be a problem if sequences were
> internally (to the Euphoria interpreter) managed as association lists, but if
> they're
> managed as arrays (as seems likely), you're complicating things pretty much
> needlessly.
Not really. In implementation terms, just do
if index < 0 then index+=length(s)+1 end if
after saving the original value of index for debugging purposes (that
way we see "error: -5 is out of bounds" instead of "error: 18 is out of bounds"
or something).
> On the other hand, using "s[$]" isn't any more complicated from the
> interpreter's (and
> Rob's, as the writer of the interpreter) point of view than would be using the
> expression
> s[length(s)] - in fact, the _translator_ could (and probably would) generate
> _exactly_ the
> same code for both.
Using s[$] is a parser change, not a run-time engine change. The 2 are
completely different and which is more complicated depends on the implementation
(tho a parser change is prolly more easy than a change to the sequence engine
in most cases).
The translator could generate the same code for negative indexes as well tho,
at the cost for some overhead.
(Implementation note: wrap all index values with fix_neg(), which takes the
index and the length of the sequence as parameters and does the implementation
I outlined above.)
>
> >The only thing i dont like is that the "-1"
> >after the two dots looks a little strange there.
>
> I'm ignoring esthetics for now. I'm interested in functionality and internal
> consistency.
Negative indexes does not affect that, except in debugging terms (yes I
admit it is likely to introduce bugs). Other than that, it wouldn't
affect anything. I should know, I've implemented it before.
>
> >What about both at the same time?
>
> >[3] using (-) indexing AND "$" for the end
>
> >s="MyFile.exw"
> >Name=s[1..6]
> >Ext=s[-4..$]
>
> >This looks pretty clear, but it involves more of a change
> >to the language then just adding "$" to it.
>
> Indeed it does - and it still possesses the disadvantages of allowing negative
> subscripting. What's more, this idea requires the maintenance of _two_
> internal
> pseudoconstants for each sequence, its length (for the use of $), and
> _one_more_than_its_length_, to support the negative subscripting,
No it wouldn't. I already showed that. (And I believe Pete L did as well in
other posts.) I can prove it to, since I've actually implemented negative
subscripts before (the length of the sequence would always have to be stored
in there for bounds checking anyways, so there would be no pseudoconstant
especially for the use of $ btw).
> as the two expressions
>
> s[$]
> s[-1]
>
> would necessarily return the same (last) element of the sequence.
Yes. Thats the idea.
> It would be simpler -
> for Rob, as the author of the language and it's normative interpreter - to
> maintain only
> the $ symbolic pseudoconstant, as all that would need be done is (essentially,
> pseudocode
> description)
>
> if token-encountered = "$" AND expression-context = sequence-subscript THEN
> return
> sequence-length
>
> (with appropriate use of variables to indicate _which_ sequence the current
> context is
> referring to).
Which would be done in the parser. No argument there.
But its not more complex to do this in the sequence engine (presumely where
bounds checking is done) (also in pseudocode description):
Save the original index.
If index is negative then add (length of sequence+1) to it.
...NORMAL BOUNDS CHECKING STARTS...
If index is still negative or index is more than length of sequence, then
raise error and use the saved index value in the error message.
......
>
> And for you and me, it doesn't add any real complexity to the language; it's
> what's often
> called "syntactic sugar", making "$" exactly equivalent to "length()" as a
> sequence
> subscript.
And -1 would be exactly equivalent to length() in a sequence subscript as well.
What of it?
>
> --
> Jeff Zeitlin
> jzeitlin at cyburban.com
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
Outlook Users, please don't put my email address in your address book. That way,
my email address won't appear in forged emails sent by email viruses. (Which are
technically worms btw :P)
24. Re: Last Element Reference
On Sun, Sep 21, 2003 at 07:15:20AM +1000, Derek Parnell wrote:
<snip>
> -- Build list.
> for i = 1 to length(s) do
> rid = routine_id(funcA(s[i]))
> if rid > length(ridlist) then
> ridlist &= repeat(-1, rid - length(ridlist))
> end if
> ridlist[rid] = DefaultValues
> end for
>
> . . . then later in program
>
> rid = routine_id(funcA(x))
> ridlist[rid] = UpdatedValues
> . . .
>
> Okay, so here we have a program that stores some parameter values that are
> indexed via the Routine_ID that they apply to. This works fine until we supply
> the funcA() routine an unknown routine name. In that case it returns a -1. Now if
> negative indexing were allowed, this would update the LAST parameter set rather
> than causing an exception. Yes, its a bug and poor programming practice, but it
> might take awhile to detect and to find.
>
> Although this is contrived, it is a realistic scenario.
>
> A similar situation could be set up for file handles returned by open() as
> that uses -1 to signal an error too.
In OE, we could do
with negative_subscript_warning
So then a warning would be generated whenever a negative subscript was
encountered.
We could be even more agressive and add a "warn_on_negative_subscript_use()"
builtin which would make the interpreter flag a warning IMMEDIATELY when the
negative subscript is used as opposed to at the end of the program.
Also a "with negative_subscript_error_compat" to make it an error to use
negative subscripts. This would be just another compat option with all the
others
we've already discussed in OE (and would of course be coverted by the ubqiuatous
"with compat").
Naturally, none of this has a chance of making it to RDS Eu (would perhaps
be too much of a headache to manage the compatibility issues for them
perhaps?) but its still worth discussing, even if it only benifits OE>
jbrown
>
> --
> Derek
>
>
> Ok, so here is a piece of code that is supposed to do something with a element
> of a sequence, but we don't know where abouts that portion starts until run time.
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
"Is there peace in heaven, or is that merely an illusion?" - Someone
25. Re: Last Element Reference
- Posted by jzeitlin at cloud9.net
Sep 21, 2003
On Sat, 20 Sep 2003 21:13:44 -0700, Pete Lomax <petelomax at blueyonder.co.uk>
wrote:
>On Sat, 20 Sep 2003 11:54:49 -0400, jzeitlin at cloud9.net wrote:
>>>All i meant was that using a negative index is 'almost' the same
>>>as using "$" minus some number. Let's compare two examples.
>>>[1] using $
>>>s="MyFile.exw"
>>>Name=s[1..6]
>>>Ext=s[$-3..$]
>>>[2] using (-) indexing
>>>s="MyFile.exw"
>>>Name=s[1..6]
>>>Ext=s[-4..-1]
>>>This is why i thought Petes idea was good.
>>But it does, as was previously indicated, remove the possibility of using a
>>check for
>>negative subscript as a flaggable error.
>No. What it does is double the number of values that can be used to
>access an existing element of a sequence, nothing as drastic as
>"remove the possibility".
>Given that you can currently index a sequence of length ten with ten
>values, possibly wrongly, changing that to being able to index it with
>twenty values, possibly wrongly, does not seem all that scary to me.
>Unfortunately, no-one has yet come up with a situation or code snippet
>which shows a bug that mirror indexes never trap.
Mmmmm... I'll concede the point. The check would then be for abs(subscript) >
length(sequence), rather than for subscript <= 0. A little more expensive in
processing
power, not apparently a major expense, though.
>I would also argue that probably more than 9 out of 10 index errors
>are out-by-one, which lands nicely on [0] and still triggers an error.
>Strange I haven't seen anyone come up with the argument that they
>would have to test their software more thoroughly. )
I don't consider it a valid argument; software should always be tested
thoroughly.
Although I will point out that calculated subscripts can, if negative subscripts
are
allowed, have some very unexpected results if (for example) you wrote s[b-a]
when you
should have written s[a-b]. If one of them would have a legal result, so would
the other.
And it wouldn't be a fencepost error, either.
>> This might not be a problem if sequences were
>>internally (to the Euphoria interpreter) managed as association lists, but if
>>they're
>>managed as arrays (as seems likely), you're complicating things pretty much
>>needlessly.
>Rob, from your knowledge of the internals of Euphoria, is my assertion
>wrong that the required change would be:
> if a<0 then a+=length()+1
> -- normal bounds checking
>I'm just interested, feel free to say yes and not do it
That _would_ be my guess.
>>On the other hand, using "s[$]" isn't any more complicated from the
>>interpreter's (and
>>Rob's, as the writer of the interpreter) point of view than would be using the
>>expression
>>s[length(s)] - in fact, the _translator_ could (and probably would) generate
>>_exactly_ the
>>same code for both.
>No. The interpreter has to keep track of what the $ applies to,
>whereas length() is explicitly told this.
True. But use of $ is context-limited, which requires the tracking anyway.
><snip>
>>if token-encountered = "$" AND expression-context = sequence-subscript THEN
>>return
>>sequence-length
>It doesn't happen very often, but which sequence length?
>a[$][b[$]..$]
Work from the inside, out, then left-to-right. Just like current subscript
referencing
with length() would do:
b[$] -> b[length(b)] (substitute "X" for this, for discussion purposes)
a[$] -> a[length(a)] (Assume that length(a) = Y, and substitute)
a[$] -> a[Y]
a[Y][X..$] ->a[Y][X..length(a[Y])]
Seems pretty clear to me. $ only refers to the sequence most immediately being
subscripted. So, in your example, the first $ subscripts a, the second
subscripts b, and
the third subscripts the sequence that a[$] refers to.
>I find the rareness aspect slightly worrying because it makes it so
>hard to properly test. Guess I'm glad it's Rob doing it.
>>(with appropriate use of variables to indicate _which_ sequence the current
>>context is
>>referring to).
>I agree, far more complicated than my suggested approach.
>If Rob really doesn't want this (and I think I can assure you he
>doesn't), then fine. I'll live.
>If you don't want it then fine, just say so, but unfortunately for all
>those listening in, it's in my nature, with something I want, to carry
>on *discussing* this if you say something I think is wrong
I can't really say that I'm against it any more; you've shown me another
approach. I
still don't particularly like the idea of negative subscripting, but I don't see
it as
being as much of a problematical construct. But allowing _both_ negative
subscripting and
$ absolutely does rub me wrong.
--
Jeff Zeitlin
jzeitlin at cyburban.com
26. Re: Last Element Reference
- Posted by jzeitlin at cloud9.net
Sep 21, 2003
On Sat, 20 Sep 2003 21:13:44 -0700, kbochert at copper.net wrote:
>On 20 Sep 2003 at 20:35, jzeitlin at cloud9.net wrote:
>> On Sat, 20 Sep 2003 17:02:14 -0700, Al Getz <Xaxo at aol.com> wrote:
>> >jzeitlin at cloud9.net wrote:
>> [deleted for bandwidth]
>> Your proposal, of allowing negative subscripts without the $, requires
>> significant
>> internal programmatic change to the interpreter -
>Sorry, no.
> s[3..$-1]
>and
> s[3..length(s)-1]
>and
> s[3..-2]
>are exactly the same thing expressed with different characters.
They mean the same thing _to_you_, who are writing programs using the
already-written
interpreter/compiler.
They are NOT, by any stretch of the imagination, the same thing
_to_the_interpreter_.
They are three different possible token-sets, which have to be processed
differently.
However, the first two forms share most of their code; in fact, the only thing
that would
be different in the processing of the first two is the need to take the extra
step of
effectively substituting "length(s)" for "$".
But see my reply to Pete Lomax.
--
Jeff Zeitlin
jzeitlin at cyburban.com
27. Re: Last Element Reference
Pete Lomax wrote:
> Rob, from your knowledge of the internals of Euphoria, is my assertion
> wrong that the required change would be:
> if a<0 then a+=length()+1
> -- normal bounds checking
> I'm just interested, feel free to say yes and not do it
Yes that looks about right, and that's another small point
against negative subscripts. Having to perform
the test:
if a < 0 then
looks trivial, but subscripting is THE most frequently
performed operation. Adding two machine instructions
would slow down many programs by a couple of percent
when interpreted, and maybe 10 percent when translated,
even if negative subscripts are never used
in that program. It would also add to the size of
translated code, although I could try
to optimize some translated code by "proving" that a
negative subscript will not occur in a given statement.
On the other hand, $ will sometimes speed up the code
and reduce the size of translated code. e.g.
x[i][1..length(x[i])-1]
vs.
x[i][1..$-1]
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
28. Re: Last Element Reference
Robert Craig wrote:
> On the other hand, $ will sometimes speed up the code
> and reduce the size of translated code. e.g.
> x[i][1..length(x[i])-1]
> vs.
> x[i][1..$-1]
Of course, I should have added that using a
"negative subscript" (-2) would also speed up this code.
It's just that the $ solution will not hurt the speed of
normal (positive) subscripts, the way that it appears
the negative subscript solution would. Nor will it
require additional subscripting code to be emitted by
the Translator. I'm sure that the vast majority of subscripts will
continue to be the normal (positive) ones that we allow today.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
29. Re: Last Element Reference
On Sat, 20 Sep 2003 20:35:22 -0400, jzeitlin at cloud9.net wrote:
>I don't recall offhand whether 0 is a valid subscript)
PLONK
30. Re: Last Element Reference
Derek wrote:
> ----- Original Message -----
> From: "Juergen Luethje" <j.lue at gmx.de>
> To: "EUforum" <EUforum at topica.com>
> Subject: Re: Last Element Reference
>
>
>> Lucius wrote:
>>
>>> I don't want negative indexing. I use to like the idea. But it is too
>>> easy for certain bugs to creep in and certain errors to go
>>> undetected for a long time.
>>
>> At the moment, I can't imagine a piece of code where something like that
>> happens. Can you give an example, please?
>>
>
> -- Build list.
> for i = 1 to length(s) do
> rid = routine_id(funcA(s[i]))
> if rid > length(ridlist) then
> ridlist &= repeat(-1, rid - length(ridlist))
> end if
> ridlist[rid] = DefaultValues
> end for
>
> . . . then later in program
>
> rid = routine_id(funcA(x))
> ridlist[rid] = UpdatedValues
> . . .
>
> Okay, so here we have a program that stores some parameter values that
> are indexed via the Routine_ID that they apply to. This works fine
> until we supply the funcA() routine an unknown routine name. In that
> case it returns a -1. Now if negative indexing were allowed, this would
> update the LAST parameter set rather than causing an exception. Yes, its
> a bug and poor programming practice, but it might take awhile to detect
> and to find.
>
> Although this is contrived, it is a realistic scenario.
>
> A similar situation could be set up for file handles returned by open()
> as that uses -1 to signal an error too.
I see now. Thanks, Derek!
Regards,
Juergen
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
31. Re: Last Element Reference
The reason I suggested this change to Euphoria was not for the benefit of the
interpreter, or translator or compiler, but for the benefit of the coder and
maintainer. I am not troubled if this change causes my programs to run a few
milliseconds slower, so long as it can save time during coding, testing and
maintenace sessions - that is far more important to me.
My issue with negative indexes is that the reader must interpret '-1' as either
of two things, depending on context. In one situation it means negative one, and
in another it means the last element of a sequence. And please don't tell me that
-1 is ALWAYS the same as the "last element of a sequence".
a = b-1
a = b[-1]
are so similar visually but mean extremely different things.
a = b-1
a = b[$]
not only look different, they also are different - there is less mental
gymnastics to do.
And don't get hung up about a 'dollar' symbol - it could be any punctuation
character or special keyword - that is not the point. The point is that '$' does
not look like an arithmetic expression whereas '-1' does, and length(X) is not an
arithmetic expression either, its a property getter - it gets the 'length'
property of the sequence X.
Really, I was just hoping for some syntactic sugar to be able to quickly refer
to the end of the sequence in context. Sorry to cause so much angst.
--
Derek
32. Re: Last Element Reference
- Posted by jzeitlin at cloud9.net
Sep 21, 2003
On Sun, 21 Sep 2003 06:45:52 -0700, Pete Lomax <petelomax at blueyonder.co.uk>
wrote:
>On Sat, 20 Sep 2003 20:35:22 -0400, jzeitlin at cloud9.net wrote:
>
>>I don't recall offhand whether 0 is a valid subscript)
>PLONK
Pete, if you had as many programming languages running around inside your head
as I do,
with as many using 0-based subscripting as 1-based subscripting, you might
momentarily
forget which ones were which, too. I don't always have the references
immediately to
hand.
--
Jeff Zeitlin
jzeitlin at cyburban.com
33. Re: Last Element Reference
I agree with derek, use any symbol you want but make it an easy
to identify single character. No minus signs.
Keep it simple with little extra typing.
Bernie
34. Re: Last Element Reference
All you really need to read of this message is. "Thank you Jeff"
Lucius L. Hilley III - Unkmar
----- Original Message -----
From: <jzeitlin at cloud9.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Last Element Reference
>
>
> On Sat, 20 Sep 2003 17:02:14 -0700, Al Getz <Xaxo at aol.com> wrote:
>
> >jzeitlin at cloud9.net wrote:
>
> [deleted for bandwidth]
>
<HUMAN SNIP>
>
> >So you're telling me you dont have to check for negative
> >subscripts here:
> >s={1}
> >s=s[$-1000,$-2000]
>
> No, I'm NOT. You absolutely have to check for negative subscripting, and
Rob has already
> included this code in the Euphoria interpreter - you will get an error if
you try to take
> s[-1].
>
> Your proposal, of allowing negative subscripts without the $, requires
significant
> internal programmatic change to the interpreter - and removes the ability
to flag an error
> if a negative subscript is encountered. Because a negative subscript
actually would mean
> something legitimate.
>
> >The only shortcut it *really* gives is when checking "$" alone:
> >s=s[1..$]
> >but anytime something is subtracted from $ you *STILL* have
> >to check for minus subscripts.
>
> Yes, exactly - and the result of subtracting from $ still MUST be
non-negative (and may in
> fact have to be positive; I don't recall offhand whether 0 is a valid
subscript) - or
> Euphoria will signal an error condition. Your proposal for 'bare'
negative subscripts
> _breaks_ that check. Or rather, makes it impossible to use that check.
>
Thank you Jeff
<HUMAN SNIP>
>
> >It's not a simple matter of esthetics. It's a matter of
> >psychology and the stress it produces. If you have to
> >pay more attention to detail, it creates more stress.
> >The more stress, the more energy the brain uses.
> >The more energy the brain uses, the slower you debug code.
>
> I have _never_ seen such a bogus argument in my life. Not even when it
was _clear_ that
> someone was trolling.
>
Thank you Jeff
> Programming is INHERENTLY about paying attention to detail. If you don't
pay attention to
> detail, and get everything exactly right, how can you be sure that the
program is going to
> do what you want it to? Hell, even _with_ that level of paying attention
to detail,
> programs still have bugs in them - and you want to introduce constructs
that will make
> bugs _less_ detectable? Programs can't do anything except what you tell
them to - and
> they can't guess, either, and even if they could, what would you - or your
users - do if
> the computer guessed _wrong_? Even those programs that act like you don't
have to be
> precise are only acting within their programming, and there are definite
limits to the
> imprecision available.
>
Thank you Jeff
<HUMAN SNIP>
> >Your mind is closed because you heard the phrase
> >"negative subscripts cant be detected easily"
> >and you think it applies across the board without
> >any question.
>
> And please do not resort to ad hominem attacks when others with experience
refuse to
> acknowledge your invalid views as valid.
>
> --
> Jeff Zeitlin
> jzeitlin at cyburban.com
>
Thank you Jeff
<HUMAN SNIP>
35. Re: Last Element Reference
Al Getz wrote:
>Any comments about the notation presented for the
>last element in a sequence and references FROM
>that element too?
>
>s={1,2,3,4,5,6,7}
>s=s[1..$3] --s={1,2,3}
>
>s=s[2$4] --s={1,2,4,5,6,7} --remove elements between 2 and 4
Implied negative with $. Such as:
Okay. That'll work. We don't need it. But I'm okay with that.
For clarification, your example says.
s = s[2$4] -- s = s[1..2] & [4..length(s)]
I'm okay with this if different tokens are used. I'll choose two
at random. Not neccessarily my preference. Just for tokens.
s[$] = s[length(s)]
s[2~4] = s[1..2] & s[4..$]
s[4~$] = s[1..4] & s[$]
See what I mean? If such a thing was added. It should use a
seperate token from the last element token
Please note, That I although I would preffer a character other than $.
I have been using it in my discussion examples. Reason: It is how we
started the discussion and is obvious to all as to what is being refferred
to.
Hip-Hip Hooray!
Hip-Hip Hooray!
Cheers to RC for speaking again. Now we have even more of his
view against negative subscripting.
In the words of the legendary Hulk Hogan. "I hear you brother."
Lucius L. Hilley III - Unkmar
Not a wrestling fan.
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: "EUforum" <EUforum at topica.com>
Sent: Sunday, September 21, 2003 01:16 AM
Subject: Re: Last Element Reference
>
>
> Pete Lomax wrote:
> > Rob, from your knowledge of the internals of Euphoria, is my assertion
> > wrong that the required change would be:
> > if a<0 then a+=length()+1
> > -- normal bounds checking
> > I'm just interested, feel free to say yes and not do it
>
> Yes that looks about right, and that's another small point
> against negative subscripts. Having to perform
> the test:
> if a < 0 then
> looks trivial, but subscripting is THE most frequently
> performed operation. Adding two machine instructions
> would slow down many programs by a couple of percent
> when interpreted, and maybe 10 percent when translated,
> even if negative subscripts are never used
> in that program. It would also add to the size of
> translated code, although I could try
> to optimize some translated code by "proving" that a
> negative subscript will not occur in a given statement.
>
> On the other hand, $ will sometimes speed up the code
> and reduce the size of translated code. e.g.
> x[i][1..length(x[i])-1]
> vs.
> x[i][1..$-1]
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
> --^----------------------------------------------------------------
> This email was sent to: l3euphoria at bellsouth.net
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
36. Re: Last Element Reference
----- Original Message ----- with my scatterings
From: <kbochert at copper.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Last Element Reference
>
>
> On 20 Sep 2003 at 20:35, jzeitlin at cloud9.net wrote:
>
> >
> > On Sat, 20 Sep 2003 17:02:14 -0700, Al Getz <Xaxo at aol.com> wrote:
> >
> > >jzeitlin at cloud9.net wrote:
> >
> > [deleted for bandwidth]
> >
>
> > >So you're telling me you dont have to check for negative
> > >subscripts here:
> > >s={1}
> > >s=s[$-1000,$-2000]
> >
> > No, I'm NOT. You absolutely have to check for negative subscripting,
and Rob has already
> > included this code in the Euphoria interpreter - you will get an error
if you try to take
> > s[-1].
> >
> > Your proposal, of allowing negative subscripts without the $, requires
significant
> > internal programmatic change to the interpreter -
> Sorry, no.
> s[3..$-1]
> and
> s[3..length(s)-1]
> and
> s[3..-2]
> are exactly the same thing expressed with different characters.
> The final form is the easiest of the three for the interpreter (2 lines of
C in Bach).
They are not the same
s = "123456789" -- so length(s) = 9
now...
s[length(s)-1] = s[3..9-1] = s[3..8]
s[$-1] = s[3..9-1] = s[3..8]
s[-1] = s[3..9-1] = s[3..8] Ok, I give you this. In one condition.
You did no math. You used an explicit -1. A literal -1. Not a variable
Now for the argument:
neg_one = 8-9
s[neg_one] = a freaking negative number for a index value.
Ambigous. Did you mean to use -1? or did you calculations
put you there by accident. Should the interpretter throw an error or
happily just assume you meant to look at the last element.
>
> >and removes the ability to flag an error
> > if a negative subscript is encountered. Because a negative subscript
actually would mean
> > something legitimate.
> >
> No reduction of error checking occurs. In both cases, the index is
checked
> against the bounds of the sequence. The only difference is where the
> index calculation occurs, and in fact the 'negative index' is superior in
that
> the "length(s)-x" occurs in compiled C code instead of interpreted
Euphoria.
>
> Karl Bochert
37. Re: Last Element Reference
- Posted by kbochert at copper.net
Sep 22, 2003
On 21 Sep 2003 at 13:49, Lucius Hilley wrote:
<snip>
> Hip-Hip Hooray!
> Hip-Hip Hooray!
> Cheers to RC for speaking again. Now we have even more of his
> view against negative subscripting.
See below for benchmark results.
>
> In the words of the legendary Hulk Hogan. "I hear you brother."
>
> Lucius L. Hilley III - Unkmar
> Not a wrestling fan.
>
> ----- Original Message -----
> From: "Robert Craig" <rds at RapidEuphoria.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Sunday, September 21, 2003 01:16 AM
> Subject: Re: Last Element Reference
>
>
> > Pete Lomax wrote:
> > > Rob, from your knowledge of the internals of Euphoria, is my assertion
> > > wrong that the required change would be:
> > > if a<0 then a+=length()+1
> > > -- normal bounds checking
> > > I'm just interested, feel free to say yes and not do it
> >
> > Yes that looks about right, and that's another small point
> > against negative subscripts. Having to perform
> > the test:
> > if a < 0 then
> > looks trivial, but subscripting is THE most frequently
> > performed operation. Adding two machine instructions
> > would slow down many programs by a couple of percent
> > when interpreted, and maybe 10 percent when translated,
> > even if negative subscripts are never used
> > in that program. It would also add to the size of
> > translated code, although I could try
> > to optimize some translated code by "proving" that a
> > negative subscript will not occur in a given statement.
> >
Some actual results for the Eu slicing benchmark using the Bach
interpreter.
a) Bach (with negative index) vs. Eu -- 95%
b) Bach (without negative index) vs. Eu -- 98%
negative index caused 3% slowdown
c) Bach (using a negative index in the benchmark) Vs. Eu 140%
uses of negative index are much faster.
Having thought that Bach used to do better on this test, I
rearranged the C code a little ---
a) Bach (with negative index) vs. Eu -- 103% (what I remember)
b) Bach (without negative index) vs. Eu -- 102%
negative index was faster!!
c) Bach (using negative index in the benchmark Vs. Eu 146%
It would seem (as usual) that the speed of Eu is heavily influenced
by the Watcom optimizer. Adding one or two machine instructions
("if (a < 0)" may require many other changes to keep the speed up.
Karl Bochert
38. Re: Last Element Reference
On Sun, 21 Sep 2003 23:32:16 +1000, Derek Parnell
<ddparnell at bigpond.com> wrote:
>Really, I was just hoping for some syntactic sugar to be able to quickly=
refer to the end of the sequence in context. Sorry to cause so much =
angst.
OI!
Play fair mate. I know you asked Rob for an enhancement and he said
yes, but it was MY IDEA that caused all this squabbling. Credit where
credit is due, sheesh <BFG>
Seriously, I'm OK with this (and it was my idea shot down in flames),
Rob's OK with this, heck he's probably chuffed people still _CARE_
about his ten year old project. And yes, he now knows he has something
lots of people really want & will BUY the next version for. (My
apologies Rob if I'm wrong on any of those points, and for putting
words in your mouth
A bit of lively debate never hurt anyone.
Pete
