1. Last Element Reference
- Posted by Derek Parnell <ddparnell at bigpond.com> Sep 18, 2003
- 557 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Sep 19, 2003
- 479 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 19, 2003
- 485 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Sep 19, 2003
- 482 views
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
- Posted by Igor Kachan <kinz at peterlink.ru> Sep 19, 2003
- 485 views
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
- Posted by Igor Kachan <kinz at peterlink.ru> Sep 19, 2003
- 492 views
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
- Posted by Igor Kachan <kinz at peterlink.ru> Sep 19, 2003
- 466 views
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
- Posted by Greg Haberek <g.haberek at comcast.net> Sep 19, 2003
- 491 views
> 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
- Posted by Juergen Luethje <j.lue at gmx.de> Sep 19, 2003
- 481 views
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
- Posted by Lucius Hilley <l3euphoria at bellsouth.net> Sep 20, 2003
- 469 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 20, 2003
- 488 views
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
- Posted by Igor Kachan <kinz at peterlink.ru> Sep 20, 2003
- 545 views
> 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
- 472 views
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
- 468 views
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
- Posted by Juergen Luethje <j.lue at gmx.de> Sep 20, 2003
- 498 views
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
- 476 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 20, 2003
- 487 views
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
- Posted by Juergen Luethje <j.lue at gmx.de> Sep 20, 2003
- 483 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Sep 20, 2003
- 495 views
----- 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
- Posted by Igor Kachan <kinz at peterlink.ru> Sep 20, 2003
- 486 views
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
- 482 views
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
- 490 views
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
- Posted by jbrown105 at speedymail.org Sep 21, 2003
- 471 views
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
- Posted by jbrown105 at speedymail.org Sep 21, 2003
- 482 views
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
- 482 views
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
- 499 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Sep 21, 2003
- 498 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Sep 21, 2003
- 479 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 21, 2003
- 481 views
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
- Posted by Juergen Luethje <j.lue at gmx.de> Sep 21, 2003
- 473 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Sep 21, 2003
- 466 views
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
- 512 views
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
- Posted by Bernie Ryan <xotron at bluefrognet.net> Sep 21, 2003
- 521 views
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
- Posted by Lucius Hilley <l3euphoria at bellsouth.net> Sep 21, 2003
- 533 views
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
- Posted by Lucius Hilley <l3euphoria at bellsouth.net> Sep 21, 2003
- 462 views
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
- Posted by Lucius Hilley <l3euphoria at bellsouth.net> Sep 22, 2003
- 445 views
----- 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
- 484 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 24, 2003
- 483 views
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