OpenEuphoria

Re: Small feature request for future EU versions

• Posted by Derek Parnell <ddparnell at bigpond.com> Oct 22, 2004
• 666 views

Patrick Barnes wrote:
> 
> Just in case this topic hasn't been discussed to death yet...

Impossible!  

> Sequence operators (= != >= <= > < + - * /) are confusing at first, I'll
> agree.
> 
> However, I do not support changing their current behaviour from
> returning a sequence comprised of the individual elements, operated
> on. Apart from the backwards compatibility...
>
> I have written many pieces of code that taken an 'object' argument,
> act on it in some way, and return it... without ever testing whether
> the object is a sequence or an atom!
> This is a tremendous benefit for Euphoria.. Try do the same thing in
> C, and it's more than likely that you'll have to write an individual
> function for every type of argument. And I don't mean just atomic or
> array types... I mean char, short, int, uint, long, double, char[],
> short[], int[], long[], double[], plus any other types that you are
> interested in. And even then it can only handle 1-d arrrays!

I agree that this is one of Euphoria's overriding strengths. It costs a bit
of runtime performance (dynamic-typing verses static-typing) but in the
long run it is wonderful.

But why *must* this functionality be implemented using operators rather
than built-in functions? In essence, it is a syntax issue and not a
semantic issue.
 
> For example: (and I'm sure it's possible to do this more efficiently,
> this is just off the top of my head)
> 
> }}}
<eucode>
> function abs(object x)
>      return x * (1 - 2*( x < 0 )  )
> end function
> </eucode>
{{{

function abs(object x)
     return x * (1 - 2*( lessthan(x,0) )  )
end function

 
> Elegant, and simple. Works for ANY object X... 
> I see this as a very important reason not to change the behaviour of
> existing operators.

Have you an estimate for how frequently the operators have actually been
used in this manner? I think there are two instances in the RDS libraries,
the case conversion routines (BTW which only work on a limited set of
characters) and ... actually I can't find the other example just now.
  
My position is that the functionalty should remain in Euphoria, but as it
is rarely used it should be implemented using (unambiguous) built-in 
functions, and the much more common comparision functionality should be
implemented using operators.

In the end, both are translated to IL for execution, so its just a matter
of which syntax to use to represent the functionality.


However, if you really insist on operators for the sequence operations, 
then as these are rarely used, a special syntax for those might be better.

function abs(object x)
     return x * (1 - 2*( x {<} 0 )  )
end function

-- 
Derek Parnell
Melbourne, Australia