|
in reply to Representing all data as Lists (Perl7?)
Your main supporting premise here is that it would add some magical degree of elegance. To be honest, I just don't see it. Different things are elegant in different situations, and a list is not always the Right Thing. I guess you could say it's elegant to form all tools into the shape of a hammer, but I disagree.
For what it's worth, you could probably emulate most of the interface you have here using tied arrays. Perhaps if I played around with something like that, I might see your point of view. But currently, I just don't. |
Re^2: Representing all data as Lists
by rje (Deacon) on Sep 20, 2005 at 17:28 UTC
|
If the implementation is the only thing that changes, then the programmer may simply see a Perl6 look and feel. I'm exploring whether or not the implementation of Perl would become simpler if there was one datatype used to represent the things we see as strings, lists, and hashes. Granted, I'm also exploring what a Perl would look like which blurred the distinctions between scalars, lists, and hashes as well.
| [reply] |
|
|
I'm exploring whether or not the implementation of Perl would become simpler if there was one datatype used to represent the things we see as strings, lists, and hashes.
It might be simpler, but it would never happen. You seem to view this as just a "matter of time" since computers will be so fast they will make up for the "inefficiency" of this LISP-y implementation. The speed of a computer is a factor, but it is probably the least important factor when it comes to "efficiency."
Constant speedups are one thing, but if you have a bad algorithm (like blindly searching a list to implement an associative array), the problem will scale poorly no matter how fast your computer is. The only way a futuristic computer running a linear-time algorithm could keep up with another computer running a constant-time algorithm would be if it could somehow compress time.
If I had to choose between a fast computer and fast algorithms, I'd choose fast algorithms ;)
You'd have a better chance of convincing me that this is a good idea if the implementation stays efficient and the everything-is-a-list is just a unifying interface to whatever the underlying structure is. Although I still don't see what this does that LISP doesn't already do.
| [reply] |
|
|
Constant speedups are one thing, but if you have a bad algorithm (like blindly searching a list to implement an associative array), the problem will scale poorly no matter how fast your computer is. The only way a futuristic computer running a linear-time algorithm could keep up with another computer running a constant-time algorithm would be if it could somehow compress time.
The good thing about these types of mental exercises is that it helps expose our shared set of (mostly hidden) assumptions. For example, we like to think that we can do array lookup (and by extension, hash lookup) in O(1) time. Geometrically though, RAM is really a tree structure, and we have wait for signals to propogate through O(log n) row and column decoders. But even this is optimistic, because if bits take up a finite volume (and the speed of light is constant), then we're really looking at O(n**(1/3)) time for a lookup.
| [reply] |
|
|
|
|
|
|
It's kind of funny, because my feelings are the opposite of what blokhead describes in the last paragraph of Re^3: Representing all data as Lists; I'd actually be more inclined to support unifying the internals than changing the interface, though I don't really think either is a very good idea.
Like I said (or maybe I should have said more clearly) in my original reply, I think different things should look different. You may say the corollary is that alike things should like similar -- and I'd agree -- but in this case I dont' think a string and a list are things that are really all that alike. I can understand why someone would say they are, but I think it's a contrived likeness.
I strongly agree with Perl's current notion that a string is an individual thing (i.e. a scalar). I don't often have the need to break that thing apart and operate on its individual characters (Update: a clarification of what I meant). Perhaps that's a learned trait, but I tend to think it's more likely that instinctively seeing a string as a list is less natural.
In the case of hashes, I don't feel as strongly as I do about strings. Hashes are very list-like already, and as you pointed out, you can already coerce a list into a hash. That's a pretty natural-feeling thing, in my eyes. I still think a hash is different enough from a plain list that it deserves its own syntax and sigil, though. And Perl 6 will make it pretty easy to get a list of pairs, or a list of interwoven keys/values:
my %hash = <one 1 two 2 three 3>;
say $_.join(" ") for %hash.pairs;
# output:
# one 1
# three 3
# two 2
say for %hash.kv;
# output:
# one
# 1
# three
# 3
# two
# 2
| [reply]
[d/l] |
|
|
I strongly agree with Perl's current notion that a string is an individual thing (i.e. a scalar). I don't often have the need to break that thing apart and operate on its individual characters.
I think most Perl programmers would disagree with that notion. Especially since Perl is one of the few languages which has elevated fold/spindle/mutilate of strings into a language construct. Of course I'm talking about Perl's pattern matching facility (A.K.A. regex, but they're really not regular in the theoretical sense).
| [reply] |
|
|
|
|
