Re: Sequence index with sequences... Why not?!
> Anders Eurenius recently suggested that Euphoria should
> allow subscripting of a sequence with a sequence. This is a
> reasonable idea. I can understand his arguments in favor of this
> feature.
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 add=
ition
to the actual data (pointer to next node, integer, whatever). If so, makin=
g
trees (and such) tricky would really feel pretty stupid...
> I'd like to point out that in addition to using recursion to
> subscript a tree of unknown depth, you can also write a
> loop that subscripts one level with each iteration.
Oh, yeah... It's tail(?)-recursive... ok. doable.
> This topic was discussed a few months ago on this mailing list,
> and the rest of this message is a copy of what I said back then...
There's an FAQ and I didn't read it. Great. <bonk><bonk>
> I've received many suggestions for defining what it would
> mean to subscript a sequence with a sequence:
Yeah, ok... how about using {} or () var and func can't have the same name=
can
they? Or maybe just s[#{}]=3D>Zeitlin, s[=A4{}]=3D>dimensional, s[%{}]=3D>=
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-magici=
ans
do weird stuff, it just means it's a powerful language...
> 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?
> 2. Other people suggested: *Anders idea too*
> (useful for tree structures of unknown depth):
> s[{a,b,c}] is s[a][b][c]
I was slightly surprised it didn't already work this way, it felt very nat=
ural
> 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?).
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...?
> So far I haven't been convinced that any of the above are really worth i=
t
Perhaps it isn't. If I can escape the overheads of recursion, I'll try to =
make
a generic tree library...
> since you can achieve the same effect fairly easily using the
> existing language. Plus the fact there are at least three choices
Yeah, but the others are totally twisted! B-)
> makes it difficult to confidently commit to one of them.
You don't have to.
> The main reason is I don't want to make the language more complicated
> without good reason.
Makes more sense. If you'd buckle every time, it would become spit and bai=
ling
wire real quick...
> Regards, > Rob Craig > Rapid Deployment Software
/Anders
--------------------------------------------------------------
Anders Eurenius <c96aes at cs.umu.se> UIN:1453793
Computer Science/Engineering student at the university of Ume=E5
--------------------------------------------------------------
|
Not Categorized, Please Help
|
|
