OpenEuphoria

Re: we need official libs : Swap

• Posted by Roderick Jackson <rjackson at CSIWEB.COM> Jul 20, 1999
• 543 views

Cuny, David wrote:
>Roderick Jackson wrote:
>
>> I think I've decided. This construct is a Bad Thing.
>> Ambiguity and exceptions abound concerning subscripts,
>> slices, off-sized sequences, and multiple instances of
>> a variable.
>
>I disagree. Implementation removes the ambiguity - it just may not work the
>way you expected.
>
>This mechanism is basically a way of getting around the fact that you can't
>pass by reference is Euphoria. This constraint often leads to unclear code,
>such as (actual example):
>
>   pt1 = mapToParent( self, x1, y1 )
>   pt2 = mapToParent( self, x2, y2 )
>   draw_line( pt1[X], pt1[Y], pt2[X], pt2[Y] )
>
>Compare that with:
>
>   { x1, y1 } = mapToParent( self, x1, y1 )
>   { x2, y2 } = mapToParent( self, x2, y2 )
>   drawLine( x1, y1, x2, y2 )
>
>I consider the second version to be much more readable.

Yes, I agree. But to be fair, if I were personally writing out this code in
one of my own programs, the first example would probably look like:

   pt1 = mapToParent (self, x1, y1)
   pt2 = mapToParent (self, x2, y2)
   x1 = pt1[X]
   y1 = pt1[Y]
   x2 = pt2[X]
   y2 = pt2[Y]
   draw_line (x1, y1, x2, y2)

which is almost as clear, but requires excess variables, pt1 and pt2,
and extra typing (albeit not much.)

Don't get me wrong, I see how handy the construct would be for that
situation. And, like I said, it looks almost alluring. But in my mind I
can't justify that use in that one slightly clearer, more efficient
example, KNOWING that:

   (1) We're going to need excess 'placeholder' variables (something we're
      trying to avoid) whenever we don't need the first x elements in the
      right-hand sequence

   (2) We'll wind up with a situation where neither 'seq[i]' nor 'seq[i..j]'
      will be interchangeable with 'var', leading to inelegant workarounds
      (like creating temporary variables to shove back into a sequence) just
      to fully use this new, elegant construct--assuming we don't just reduce
      the construct to several sequential assignments; OR

   (3) We lose the ability to swap, which is one of the arguments in favor
      of the construct--assuming we DO just reduce the construct to several
      sequential assignments

and finally,

   (4) No matter how certain aspects of it will be implemented (multiple
      variables on the left, off-sized sequences, etc.,) the results won't
      be immediately obvious unless you *know* how it's being implemented
      (and to be honest, I don't think I like the idea of ambiguity being
      cleared up via one specific implementation...)

With those knocking at the back of my mind, I just can't come out in favor
of it. I value design consistency, simplicity, and lack of ambiguity--on
the syntax level--more than I do brevity and elegance in a single situation.

I think that's the bottom line that determines which side we each take on
the issue... is the addition worth those problems, when we KNOW they'll come?

(One might suggest that theoretically we should be able to close our eyes to
the implementation, but that's just not possible with this construct--which
says something by itself. There's no way of knowing how

   {s[i], s[j]} = my_func ()

evaluates when i=j without knowing how it's implemented.)


Rod