OpenEuphoria

Re: Small feature request for future EU versions

• Posted by Patrick Barnes <mrtrick at gmail.com> Oct 22, 2004
• 639 views

On Thu, 21 Oct 2004 20:27:48 -0700, Derek Parnell
<guest at rapideuphoria.com> wrote:
> 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.

Well, using functions rather than operators it looks ungainly, and
requires more typing. In addition, they can be difficult to quickly
comprehend when you are reading through source:

if A {<=} B then
Vs:
if compare(A, B) <= 0 then

I don't even know if the two are functionally the same! I can't
remember whether compare is supposed to return a positive or a
negative value in which case!

 > }}}
<eucode>
> function abs(object x)
>      return x * (1 - 2*( lessthan(x,0) )  )
> end function
> </eucode>
{{{


Yes, that could work... but there are more important considerations...
(see below)

> 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.

Don't forget that the RDS libraries are missing many basic functions
like the aforementioned abs... I'm reasonably sure this functionality
gets used more often in things like genfunc, etc...

My projects have used sequence operators whenever I see them as being
appropriate.

> 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.

I think this would be a grave error. Initially, I thought "yeah,
that's a great idea, it makes more sense"... and it does. But... (see
below)

 
> 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.
> 
> }}}
<eucode>
> function abs(object x)
>      return x * (1 - 2*( x {<} 0 )  )
> end function
> </eucode>
{{{


Actually, I initially thought that too. After all, it makes as much
sense as the solution I proposed in the earlier thread, if not
more....

PROBLEM! Backwards compatibility. Not that we haven't heard it shouted before...
It's worse than regular backwards compatibility problems though... 
Consider: Should it be changed, every program that uses sequence
operators will have a different behaviour.

eg: 
X = a[i] + (b[j][m] > c[p][2]) 

However, there will be no obvious error message. Rather than the line
above executing as expected, with a[i] being added to by an array,
it'll be added to by an atom. Who knows what will happen?
Of course, nothing could happen... if b[j][m] and c[p][2] are atoms.
But are they? I have no idea, and neither will anyone searching
through source changing things over.
There's no way to detect whether this will affect code.


That's why I suggest the new {=} apply to sequence comparison. After
all, it *is* logical for given values of 'logical', and it won't break
any existing code.

-- 
MrTrick