1. Re: Suggested Extension to Euphoria Language

Ad Rienks <Ad_Rienks at COMPUSERVE.COM> suggested in response to my
idea for extending Euphoria:

E::>function extract(sequence from, sequence index)
 ::>-- returns indexed elements from a sequence
 ::>sequence into
 ::>        into = repeat(0, length(index))
 ::>        if index[length(index)] > length(from) then     -- test for bad inde
xing
 ::>                puts(1, "BAD INDEX!\n")
 ::>                return 0
 ::>        end if
 ::>        for magic = 1 to length(into) do        -- or to length(index), that
's the same
 ::>                into[magic] = from[index[magic]]
 ::>        end for
 ::>        return into
 ::>end function    -- extract

 Well, not quite - since the subscripts could be in any order,
 not strictly ascending, I would need

 global function extract(sequence from, sequence subscripts)
        sequence result

        result = {}
        for i = 1 to length(subscripts) do
                if subscripts[i] > length(from)
                        puts(1, "Subscript Out Of Range!\n")
                        abort(1)
                else
                        append(result,from[subscripts[i]])
                end if
        end for
        return result
 end function

 ...which is simply an encapsulation of the code that I
 originally compared my proposal to, with a little bit of error
 checking.  It works, certainly - my concern wasn't that I
 couldn't write code to do it; only that it wasn't really
 "Fsthetic".

 A secondary reason for the proposal was the observation that
 many functions that "classically" work only on single numbers
 (basic math operations, trig functions, etc.) have been
 implemented in Euphoria to be able to work on sequences of
 numbers within their domain, in a manner analogous to my
 proposal - or rather, my proposal was an analogous extension to
 array subscripting.

 Robert Craig <robert_craig at COMPUSERVE.COM> then goes on to
 say...

E::>Thanks to Jeff Zeitlin for his suggestion.

E::>I've received many suggestions for defining what it would
 ::>mean to subscript a sequence with a sequence:

E::>1. Jeff's idea (it's done like this in APL):

E::>    s[{a,b,c}] is {s[a],s[b],s[c]}

 Good point about the parallel to APL - and, as I pointed out
 above, consistent with the way you've extended basic operators
 and functions (i.e., similar to APL, x = {1,2,3} + {4,5,6} is
 legal in Euphoria, as is sin({0, pi/2, pi, 3*pi/2})).

E::>2. Someone else suggested (useful for tree structures of unknown depth):

E::>    s[{a,b,c}] is s[a][b][c]

E::>3. Someone else suggested (the database people would like it):

E::>    s["Fred"] is the Euphoria object associated with "Fred" e.g.
 ::>               s["Fred"] = 99
 ::>               s["Dave"] = 27
 ::>               s["George"] = {1,2,3}

E::>    Euphoria would try to look up "Fred" in s
 ::>    in some efficient way (linear search, hashing, whatever).
 ::>    If "Fred" couldn't be found it might fail, or perhaps
 ::>    return some special value (what value?).

 Ideas 1 & 2 are clearly mutually exclusive, and apparently
 irreconcilable.  I think that either 1 & 3, or 2 & 3, could
 both be implemented, with a minor change to the syntax in 3 -
 instead of using foo["bar"], require foo[{"bar"}] instead.
 This would allow mixing of associative and indexed references,
 and provides a "flag" of sorts to indicate whether indexing or
 association is required - if the element of the sequence is
 itself a sequence, then we're talking associative referencing;
 if it's a simple integer, we're talking indexed referencing.

 One of the points to make about 3, even modified, is that it
 effectively implements a nice feature of SNOBOL and LISP that I
 have seen in no other language - association lists (SNOBOL)/
 property lists (LISP).  If it can be done without bogging the
 interpreter, I'd put my vote behind this idea, too.

E::>So far I haven't been convinced that any of the above are really worth it,
 ::>since you can achieve the same effect fairly easily using the
 ::>existing language. Plus the fact there are at least three choices
 ::>makes it difficult to confidently commit to one of them.
 ::>The main reason is I don't want to make the language more complicated
 ::>without good reason.

 Understandable, and it's your baby.  At least you're willing to
 listen and discuss the ideas with the people who propose it.
 Have you ever tried to put a proposal in front of an ANSI/ISO
 working group?  Without being an official member of the group?

 Oh - one useful trig function that you seem to have forgotten
 to implement - arctangent!

 =========================================================================
Jeff Zeitlin                                      jeff.zeitlin at execnet.com
---
 ~ OLXWin 1.00b ~ "Garlic roll, Barnabas?" "Garlic? Aieeeee!!"

new topic     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu