1. Re: [E - 6 to 7 Jun 1997] Sub'ing seqs with seqs
- Posted by JEFF ZEITLIN <jeff.zeitlin at EXECNET.COM> Jun 09, 1997
- 624 views
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.