OpenEuphoria

Re: Last Element Reference

• Posted by jzeitlin at cloud9.net Sep 21, 2003
• 481 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