OpenEuphoria

RE: A question about certain language features

• Posted by bensler at mail.com Mar 21, 2002
• 508 views

Karl,

   Consider this syntax for shorthand slicing. Your current syntax sort 
of defeats the sequence bounds checking.

seq[1..0] -- seq[1..length(seq)]
seq[1..0-1] -- seq[1..length(seq)-1]

seq[1..1-1] -- {} (reverse slice)
seq[1..-1] -- index [-1] out of bounds

integer index   index=0
seq[1..index] -- {} (reverse slice)

'O' is explicit, it cannot be implied. If it is, the original EU rules 
apply.

I haven't thouroughly looked. Does your shorthand work if it's implied 
with a variable?


Chris

kbochert at ix.netcom.com wrote:
> -------Phoenix-Boundary-07081998-
> Content-type: text/plain; charset=ISO-8859-1
> Content-transfer-encoding: 8bit
> 
> Hi Derek Parnell, you wrote on 3/20/02 7:41:44 PM:
> 
> 
> >I think that the primary reason for wanting to initialise variables when
> >they are being
> >declared is
> >simply because it is convenient and reduces the chance of forgetting to 
> >do
> >it. The current
> >syntax
> >for doing this only works outside of routines:
> >
> >  integer x x = 5
> >  integer y y = 6
> >
> >the argument is that this is not a particularly pretty solution. For
> >example:
> >
> >  integer CustomerResidentialAddressIndex  CustomerResidentialAddressIndex
> >= 1
> >  integer CustomerMailingAddressIndex CustomerMailingAddressIndex = 1
> >
> 
> My ?favorite? example of this kind of redundancy is something like:
> 
> CustomerResidentialAddressIndices = 
> CustomerResidentialAddressIndices[2..
> length (CustomerResidentialAddressIndices)]
> 
> An earlier fix I tried allowed the oddball syntax:
> 
> @foo[2..]
> 
> to be equivalent of:
> 
> foo = foo[2..length(foo)]
> 
> 
> >Why not? It is inconsistent behaviour. I suggest it has been done this
> >way just so that writing the interpreter was easier for RDS.
> > I can not think of any other reason yet.
> 
> I think that the only reason for this can be because Rob wants it
> that way.
> It took me 2 months to add a dozen 'enhancements' to Eu, and most
> of them were very easy once I understood the code sufficiently.
> You have got to believe that Rob could add these features in a
> week (maybe a month, with extensive testing).
> 
> >
> >But real problem is the *initialisation* of variables
> >and run-time control of that initialisation,
> >Travis, in his article, explains the real problem,
> >solved in Euphoria, not a problem of some individual taste.
> >
> 
> I know its been here before, but could someone point me to this
> article again?
> 
> 
> >> > > 2) No support of call by reference.  I understand that call
> >> > > by reference can lead to unexpected side-effects, but since
> >> > > changing global variables in a subroutine seems to
> >> > > essentially cause the same problem, I don't understand this
> >> > > omission.
> 
> As near as I can see, Pass By Reference involves a 'deep' change
> to the language. Every modification to every passed variable
> must check if the variable is a reference. This single extra
> check would noticeably slow down all programs, violating a
> prime design goal of Eu.
> I partially implemented PBR and was surprised to find that
> it slowed any program that did not use it extensively by
> 10-15%.
> 
> 
> Karl Bochert
> 
> 
> -------Phoenix-Boundary-07081998---
>