1. Re: [E - 6 to 7 Jun 1997] Sub'ing seqs with seqs

Anders Eurenius <c96aes at OXE.CS.UMU.SE> writes...

E::>Thank you. The way I'm figuring it, sequences are stored as linked lists.
 ::>The node-type is some kind of datatype tag (as prolly all objects have) in a
ddition
 ::>to the actual data (pointer to next node, integer, whatever). If so, making
 ::>trees (and such) tricky would really feel pretty stupid...

 You may be right - but the actual method of storage turns out
 to be irrelevant, since you (the Euphoria programmer) can't
 take advantage of it in any sensible way - Euphoria is
 _strictly_ and _universally_ call by value from your point of
 view, even though Robert has written it to handle actual
 storage efficiently.  As far as you're concerned, it doesn't
 matter whether the actual implementation is more akin to your
 description or to a simple array - to you, it looks like an
 array.  Period.

E::>Yeah, ok... how about using {} or () var and func can't have the same name c
an
 ::>they? Or maybe just s[#{}]=>Zeitlin, s[${}]=>dimensional, s[%{}]=>associated
...
 ::>Sure, I do get the part about complexity though, but the way I see it, it's
 ::>easy to learn the basics, and that's what's important. If the black-magician
s
 ::>do weird stuff, it just means it's a powerful language...

 Robert's position is that if you can accomplish the same aims
 using the existing Euphoria capabilities, there's no reason to
 add more syntax oddities - and this idea is, quite honestly,
 "oddity-er" than most.  I've written a set of routines that
 implements the "Zeitlin/APL" idea, and one that implements the
 associative table/array idea.  They're available from the
 Euphoria home page, but don't download them yet; wait for
 Robert to announce that he's received the revised package I'm
 sending simultaneously with this message.

E::>> 1. Jeff Zeitlin's idea (it's done like this in APL):
 ::>>     s[{a,b,c}] is {s[a],s[b],s[c]}
 ::>Kinky! Hey Jeff! Does it do any cool tricks?

 Well, I've implemented this with a function, rather than
 preprocessing this syntax, so you actually call it as
 xslice(s,{a,b,c}).  It allows you to take non-sequential
 elements, and they don't have to be in ascending index order.
 The operational structure of the routine should be fairly
 obvious; I loop on the sequence (call it k) and build up and
 eventually return a sequence consisting of all the elements
 s[k[i]], i=1..length(k).

E::>> 3. Someone else suggested (the database people would like it):
 ::>>     s["Fred"] is the Euphoria object associated with "Fred" e.g.
 ::>>                s["Fred"] =3D3D 99
 ::>>                s["George"] =3D3D {1,2,3}
 ::>>
 ::>>     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 =3D
 ::>>
 ::>>     return some special value (what value?).

E::>Easy: junk token like nan, or something. But, uhh, what is this associated
 ::>object thing? How's this: it's a giant sequence, and links are kept as
 ::>index-sequences...?

 I've implemented this (see my file assoc.e - the revised one,
 which works); it's actually a three-element sequence: the first
 element is the user-definable default (which defaults to an
 empty sequence), the second element is a sequence where each
 element is a key, and the third element is a sequence where
 each element is the value associated with the corresponding (by
 index) key.  There are a whole set of routines for setting a
 key/value pair, deleting one, changing the value, setting or
 changing the default, and so on.

 =========================================================================
Jeff Zeitlin                                      jeff.zeitlin at execnet.com
---
 ~ OLXWin 1.00b ~ Avoid cliches like the plague.

new topic     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu