Re: RFC 84 (v1) Replace = (stringifying comma) with =
"RA" == Russ Allbery [EMAIL PROTECTED] writes:
RA Damien Neil [EMAIL PROTECTED] writes:
Arrays are ordered. Hashes are not. Sure, you can iterate over a hash,
but add an element to one and you can change the order of everything in
it.
RA Formally, I believe it's permissable for a hash implementation to
RA return a different order the second time you iterate through it
RA from the first time, even if you haven't touched the hash
RA inbetween. That's the definition of an iterable but unordered
RA data structure; there's some way of getting all of the members one
RA and only one time, but each time you look at it the order in which
RA the members show up may be different (maybe garbage collection
RA happened behind the scenes, the hash was reorganized due to an
RA observation of how you were using it, etc.).
this will break this use of hash slices:
%add_hash = ( foo = 3, bar = 4 ) ;
%new_hash = ( joe = 5, mary = 8 ) ;
@new_hash{ keys %add_hash } = values %add_hash ;
in fact this feature is not really well documented but it is used and
relied upon. at any point a hash should have the same order of iteration
so you can correlate a list of its keys to a list of its values.
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Tue, Aug 15, 2000 at 11:46:04PM -0400, Stephen P. Potter wrote: Why is it silly? Hashes and arrays are *conceptually* very similar (even if they are extremely different implementation-wise). One of them has implicit key, the other has an explicit key. They both provide some sort of ordered collection (plural), even if it is difficult to understand what the order is of hashes. Seems to me we could eliminate arrays and just keep hashes. Arrays are ordered. Hashes are not. Sure, you can iterate over a hash, but add an element to one and you can change the order of everything in it. You are guaranteed that won't happen with an array. Looking up a value in an array is faster than doing so with a hash. Appending a value to an array is usually faster than adding an element to a hash, but inserting elements into the middle of a large array will generally be slow. Hashes consume more space than arrays containing the same number of values. Plenty of other differences. Sure, most of them are connected to the implementation and efficiency, not the abstract concept of arrayness and hashness -- but Perl is a Practical language, and practical programmers like to know these things. You can change a lot of these things by twiddling with the internal implementations, but at the end of the day "ordered set" and "mapping" are conceptually and practically different beasts. I don't think there is any reason for Perl to want to toss away the distinction. - Damien
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Damien Neil [EMAIL PROTECTED] writes: Arrays are ordered. Hashes are not. Sure, you can iterate over a hash, but add an element to one and you can change the order of everything in it. Formally, I believe it's permissable for a hash implementation to return a different order the second time you iterate through it from the first time, even if you haven't touched the hash inbetween. That's the definition of an iterable but unordered data structure; there's some way of getting all of the members one and only one time, but each time you look at it the order in which the members show up may be different (maybe garbage collection happened behind the scenes, the hash was reorganized due to an observation of how you were using it, etc.). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Array storage (was Re: RFC 84 (v1) Replace = (stringifying comma) with =)
Lightning flashed, thunder crashed and "Jeremy Howard" [EMAIL PROTECTED] whispered:
| No, neither proposal makes sense. Arrays can be stored compactly and
|
| $a[1_000_000_000] = 'oh, really?' # :-)
|
| my int @a: sparse;
| $a[1_000_000_000] = 'Yes, really!' # :P
|
| OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute yet.
| My point is that arrays *can* be stored compactly, not that they always
| *are*. Another type of array storage is that required for lazily generated
Isn't this just as true, maybe even moreso for hashes? How much storage is
taken up by
$a{1_000_000_000} = "Sparse, without any special code!";
-spp
Re: Array storage (was Re: RFC 84 (v1) Replace = (stringifying comma) with =)
Stephen P. Potter wrote:
Lightning flashed, thunder crashed and "Jeremy Howard" [EMAIL PROTECTED]
whispered:
| No, neither proposal makes sense. Arrays can be stored compactly and
|
| $a[1_000_000_000] = 'oh, really?' # :-)
|
| my int @a: sparse;
| $a[1_000_000_000] = 'Yes, really!' # :P
|
| OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute
yet.
| My point is that arrays *can* be stored compactly, not that they always
| *are*. Another type of array storage is that required for lazily
generated
Isn't this just as true, maybe even moreso for hashes? How much storage
is
taken up by
$a{1_000_000_000} = "Sparse, without any special code!";
Yes, in this case (it wasn't my example!). But I would hope that we provide
a way of providing compact array storage where we need it. This would be
useful for lists of floats or ints that will be frequently iterated through
and directly manipulated. Image processing and statistical analysis come to
mind as obvious applications. Anyway, this is hard to discuss without an
RFC... I'm sure I've get some time to write one someone around here...
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 11:46 PM 8/15/00 -0400, Stephen P. Potter wrote: Lightning flashed, thunder crashed and Dan Sugalski [EMAIL PROTECTED] whispered: | Doesn't it make more sense to get rid of arrays and just use hashes? | | I guess it depends on what you think makes sense; but it seems to me | that an array is a more fundamental data type; that it's easier (i.e. | more efficient) to build associative arrays from arrays, than vice versa. | | It's silly to throw either of them out. Perl might be many things, but a | reductionist language it ain't... Why is it silly? Hashes and arrays are *conceptually* very similar (even if they are extremely different implementation-wise). It's because they've got so different an implementation, and their performance characteristics are so different. They're also conceptually distinct. While there is a lot of overlap, there's also a rather large area of difference. While you can fake one with the other, it doesn't mean you should. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Lightning flashed, thunder crashed and Russ Allbery [EMAIL PROTECTED] whispere d: | Arrays are ordered. Hashes are not. Sure, you can iterate over a hash, | but add an element to one and you can change the order of everything in | it. | | Formally, I believe it's permissable for a hash implementation to return a | different order the second time you iterate through it from the first What stops us from imposing order on this chaos? If they are currently defined as not having any specific order, why can't we say they always return in numeric || alphabetic || ASCII || whatever order we want? The internal storage implementation can be kept seperate from the external interface. A hash *should* be able to be advantageous over an array in just about all respects, except maybe size. And, we've shown how a sparse array can be handled in a hash without any special machinations. -spp
Re: RFC 84 (v1) Replace = (stringifying comma) with =
"Stephen P. Potter" [EMAIL PROTECTED] writes:
Lightning flashed, thunder crashed and Russ Allbery [EMAIL PROTECTED] whispere
d:
| Arrays are ordered. Hashes are not. Sure, you can iterate over a hash,
| but add an element to one and you can change the order of everything in
| it.
|
| Formally, I believe it's permissable for a hash implementation to return a
| different order the second time you iterate through it from the first
Actually not. See "perldoc -f values":
] ...The actual random order is
] subject to change in future versions of perl, but it is guaranteed to
] be the same order as either the Ckeys() or Ceach() function would
] produce on the same (unmodified) hash...
What stops us from imposing order on this chaos? If they are currently
defined as not having any specific order, why can't we say they always
return in numeric || alphabetic || ASCII || whatever order we want?
Efficiency. If I just want to map over all elements stored in a hash,
I just want the fastest access to all the elements. If I want to
access the hash by ASCII order of keys, I can `sort keys %hash'.
Think of the keys as being returned in some "efficient" order. The
specific "efficient" order is not specified, but it's guaranteed to be
a fast way to iterate over all keys.
The internal storage implementation can be kept seperate from the external
interface. A hash *should* be able to be advantageous over an array in
just about all respects, except maybe size. And, we've shown how a sparse
array can be handled in a hash without any special machinations.
for (@array) {
# stuff with $_
}
is fast.
for (values %hash) {
# stuff with $_
}
(or the roughly equivalent for loop with `keys %hash' and while loop
with `each %hash') is fast.
for (sort keys %hash) {
# stuff with $hash{$_}
}
is not so fast. So defining a sorted order would negate the advantage
of hashes over arrays you refered to.
It seems like a tied hash would be suitable for what you want. If
ties were efficient, it would be trivial to implement a SortedHash
which would perform "each"-style accesses in sorted order. Standard
Perl library, anyone?
--
Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED]
Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`-
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Nathan Torkington wrote:
Perl makes easy things easy. Hashes are bloody useful, as the last
decade of Perl has borne out. They deserve syntactic support because
they're used a lot and are worthy of a shorthand.
my @aa :assoc;
$aa['foo'] = 'bar';
Is no one getting my point?
The ability of arrays to be indexed by strings, or by any other arbitrary
data type/structure, and, more importantly, for the indexing algo to
be based on a hashing function, or anything else, should be user-
selectable, with certain schemes predefined for your convenience -- the
current hash implementation being the obvious example of that.
I suppose this has more to the with the "Improve Tie" subject, but
what I'm arguing for here is syntactic transparency between regular
arrays and any other kind of arrays (including associative arrays).
Since the range of available syntactic cues -- [] vs {} -- is so limited,
it would be better to have just one, and let the user bind the indexing
scheme to the variable.
--
John Porter
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Jarkko Hietaniemi wrote:
Arrays can be stored compactly and
$a[1_000_000_000] = 'oh, really?' # :-)
But that is far less common than
@a{ 0..100 } = (...);
which, if stored in a hash, would not only be significantly less
efficient than an array, but could generally be expected to elicit
some pathological behavior of the hashing function.
--
John Porter
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 11:09 AM 8/16/00 -0400, John Porter wrote: Dan Sugalski wrote: Numbers and strings really aren't different things, at least not as far as people are concerned. They are for machines, but computer languages ultimately aren't for machines, they're for people. I guess I can't fault you for towing the party line on this... Would you stop that? I'm not toeing anything. If I disagreed, believe me you'd hear about it. Strings and numbers are not *exactly* the same, even to humans, are they? At many levels, yes they are. After a point they differ, but what you see written is pretty much treated the same. Most numbers have no solid meaning to people without actual though. IIRC you get zero, one, two, and lots. The difference between numbers and strings is analogous to -- or, on further reflection, IDENTICAL to -- the difference between arrays and associative arrays. (The former are numerically indexed, the latter indexed by strings.) The analogy doesn't hold. And people treat arrays and hashes *very* differently, far more so than the trivial differences in the notation might lead you to believe. I'm not presuming that, though there are plenty of languages already that have no symbols. Perl's not one of them, though. Now you're appealing to the argument that "if we changed the language to be like that, it simply Wouldn't Be Perl." Not buying it. That's fine, I'm not selling it. It is, nonetheless, rather true. It's going to always be more difficult. You need to *think* to turn a word into a symbol. = is already a symbol. Less effort's needed. I guess I'm not sure what you're getting at here. In the expression Cfoo( bar ), bar is a symbol, regardless of its type. There's no "turning a word into a symbol" going on that I can see. Not symbol to the computer, symbol to the *person*. Human's higher-reasoning capabilities are all symbol based, and a lot of the brain is set to turn external stimuli into symbols to be processed. The visual cortex is good at recognizing things and tagging them with a symbol. When you see a dog, for example, it gets tagged with the symbol for dog. If you're familiar with it, it might get a more specific symbol--a breed, or even an individual. That doesn't happen with words--they're already abstract symbols, though in a different way. Because of that they get recognized at a lower level and passed to the language centers for translation to symbols. That extra handoff and translation takes time and mental effort. ...exploiting instinct and inherent capabilities give you faster response times, and quicker comprehension. Sure. But "instinct and inherent capabilities" do not apply here. Yes, they do. People write source. People read source Sure. No argument there. Nonetheless, humans certainly have no instincts, and very likely no inherent capabilities, relevant to computer programming, except for abstract reasoning, which IMHO does not favor one side of this argument over the other. That's an incorrect presumption. Humans have instinct and inherent capabilities for symbol manipulation, language, and pattern matching. That's what's used to write programs and, while it's not ideally suited to the task, it's what we've got. Taking advantage of those human capabilities is one of the things that perl does better than most other languages. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Wed, Aug 16, 2000 at 12:48:12PM -0400, Dan Sugalski wrote: At 11:09 AM 8/16/00 -0400, John Porter wrote: The difference between numbers and strings is analogous to -- or, on further reflection, IDENTICAL to -- the difference between arrays and associative arrays. (The former are numerically indexed, the latter indexed by strings.) The analogy doesn't hold. And people treat arrays and hashes *very* differently, far more so than the trivial differences in the notation might lead you to believe. Could you come up with concrete examples that illustrate this point? What would stop people from treating arrays and hashes differently if the trivial notational differences are removed? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Devils advocacy (Re: RFC 84 (v1) Replace = (stringifying comma) with =)
* John Porter ([EMAIL PROTECTED]) [17 Aug 2000 03:02]: Nathan Torkington wrote: John Porter writes: I really don't feel that strongly about it! If you think something is good, then argue for it. If you don't, don't. I *do* think it's good. I'm arguing for it because it's something I'd like to see happen. But I'm not passionate about it. Additionally, someone else may take to the idea and then argue passionately for it. They just may not have thought enough about the topic to come up with the idea. How often have you ever said "Hey! That's cool! Wish I'd thought of that!"? cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ Emacs is a nice OS - but it lacks a good text editor. That's why I am using Vim. -- Anonymous.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
[EMAIL PROTECTED] (Nathan Torkington) wrote on 15.08.00 in [EMAIL PROTECTED]: Stephen P. Potter writes: Why is it silly? Hashes and arrays are *conceptually* very similar (even if they are extremely different implementation-wise). If that were the case, I think students would have an easier time grasping hashes. It seems very common (yes yes, you all got them immediately, but merely by piping up and saying so, you do not invalidate my point, so please don't) that beginners take a long time to use hashes because they find them hard to get their heads around. I see two possible reasons for that: 1. Hashes aren't explained right. 2. They already know about computers and arrays. To someone who doesn't know about computers and arrays, hashes are the more natural concept, because they are how you do stuff like that in real life, and arrays are just a special case of hashes. There's a reason symbol tables are hashes and not arrays: people are better with names than with numbers. (Of course, one of the problems with hashes is the name. For most purposes, the fact that a (non-tied) hash uses hashing is completely irrelevant to someone learning the language.) Perl really goofed here. The generic concept should be the collection. Collections can be indexed in lots of different ways, and (Perl) hashes and arrays are just two of many options. (Think of trees, for example.) This isn't why it's silly, just a comment on the idea that hashes and arrays are conceptually very similar. Well, they are. world. I like Perl being able to optimize internally based on my simple one-character data typing (%). I'd actually prefer if the computer could work that out for itself. That's the type of stuff computers are supposedly good at. MfG Kai
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 09:49 PM 8/16/00 +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (Dan Sugalski) wrote on 15.08.00 in [EMAIL PROTECTED]: At 06:04 PM 8/15/00 -0400, John Porter wrote: Dan Sugalski wrote: Generality good. For many things, yes. For computers, say. For people, no. Generality bad. Specificity and specialization good. People aren't generalists. They're a collection of specialists. The distinction is important. I'm sorry if I don't find this argument convincing. This argument suggests that *every* type carry a distinguishing prefix symbol -- including ones to distinguish between numbers and strings, say. Numbers and strings really aren't different things, at least not as far as people are concerned. Bovine excrement. Numbers and strings completely different things to people. After a certain point, yes, more or less. Up until then, no. And most numbers are, in most contexts, treated as adjectives by people, where they have little more meaning than any other adjective. They're just mental symbols tacked on as a modifier to other symbols. Hashes and arrays, OTOH, really aren't different for people. The concept of an index needing to be a nonnegative number is a computer concept. Arrays are essentially sequences of things--first thing, second thing, third thing, and so on. Hashes, on the other hand, are named things--the person that's Bob, the person that's Jim, the person that's Jason. It's the difference between position and identity. Those are very, very different concepts. They are for machines, but computer languages ultimately aren't for machines, they're for people. I agree that computer languages are for people - in fact, that's the sole reason they were invented. Otherwise we'd still program in machine language. This statement isn't, strictly speaking, true. Very few computer languages are actually designed *for* people. Most of them are designed to map over a particular problem space, be it theory or hardware. C wasn't designed for people. Neither was Lisp, or Fortran. COBOL, oddly enough, was, though it shows the limitations of the machines and techniques of the era. People are generally an afterthought. However, I do think your ideas about what does and does not come naturally to people are incredibly warped. Perhaps, but then again perhaps not. I've got two young children. Watching kids as they grow lends a certain perspective on things. I see what does and doesn't come naturally. When designing perl, a book on cognitive psychology or early childhood education may be as (if not more) useful than a CS text. I'm not presuming that, though there are plenty of languages already that have no symbols. Perl's not one of them, though. I presume you mean $@% when you say symbols (and not, for example, the stuff that goes into a symbol table, because I certainly don't know any language that doesn't have those). Yep. It's an open question if these are a good idea. I'm not convinced. Personally, I see them as one of the ugly warts in Perl. Even assuming highlander types, the punctuation carries a rather significant amount of contextual information very compactly. s/significant/in/ IMNSHO, even ignoring the "even" part. A single small picture, and one that can be easily picked out by your visual cortex, carries an awful lot of contextual information with it, and carries it quickly. YHO is, I think, incorrect. It's going to always be more difficult. You need to *think* to turn a word into a symbol. = is already a symbol. Less effort's needed. Maybe *you* have to think to turn a word into a symbol. Most people seem to grow up with that concept. I'll have to check, but I'm not sure 'most' is appropriate here, as a large portion of the world uses iconographic languages. Regardless, more mental effort is needed to turn the word "rock" into the concept of a rock than a picture of a rock does. It's not conscious, generally speaking, but more of your brain is involved in dealing with words than with pictures. As for *recognizing* the stuff, ever heard of redundancy? It's the stuff that makes recognizing stuff easier. No, redundancy is the stuff that makes recognizing things more reliable. Words, by being longer, are easier to recognize than non-alphabetic symbols. Non-alpha symbols are *faster* to recognize. That's their advantage. Overloading them with too much meaning is bad, as then you end up needing to think more. When you see something like: $foo the first thing that happens is your brain picks out the whole space-separated thing as a single 'thing'. That happens in your visual cortex, it's fast, and takes very little effort. That gets stripped down into pieces. Your brain's already dealing with a perl context, and $ gets recognized as the 'single thing' marker. 'foo', meanwhile, is wending its way through your language centers. That's slower. The thinking part of your brain ultimately gets
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Dan Sugalski writes: Unfortunately, I think you're somewhat under-informed as to the inherent capabilities of people's brains. Ok, at this point I think all parties have to step away and let the RFCs fall where they will. It's obvious that there are two types of people: those who don't mind the punctuation, and those who do. We already know what Perl is like with punctuation. Let the anti-punctuation folks make their RFCs, and let Larry decide. I think they're wasting their time, but it's not about what I think. And somewhere within those python-esque convolutions, there may be some ideas that Larry will adopt. Nat
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Well said! Nathan Torkington wrote: Dan Sugalski writes: Unfortunately, I think you're somewhat under-informed as to the inherent capabilities of people's brains. Ok, at this point I think all parties have to step away and let the RFCs fall where they will. It's obvious that there are two types of people: those who don't mind the punctuation, and those who do. We already know what Perl is like with punctuation. Let the anti-punctuation folks make their RFCs, and let Larry decide. I think they're wasting their time, but it's not about what I think. And somewhere within those python-esque convolutions, there may be some ideas that Larry will adopt. Nat
Re: RFC 84 (v1) Replace = (stringifying comma) with =
"KH" == Kai Henningsen [EMAIL PROTECTED] writes: KH Hashes and arrays, OTOH, really aren't different for people. The concept KH of an index needing to be a nonnegative number is a computer concept. I don't know about that. Good old PL/I had arbitrary ranges for array indices. Hmm, I feel an RFC coming on my @arr :low(-32000) :high(+32000); my @population :low(1900) :high(2039); $population[1923] = 323000; How about my @population[1900:2039]; Looks funny though. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Hashes vs arrays (was Re: RFC 84 (v1) Replace = (stringifying comma) with =)
Chaim Frenkel wrote: "KH" == Kai Henningsen [EMAIL PROTECTED] writes: KH Hashes and arrays, OTOH, really aren't different for people. The concept KH of an index needing to be a nonnegative number is a computer concept. I don't know about that. Good old PL/I had arbitrary ranges for array indices. Hmm, I feel an RFC coming on my @arr :low(-32000) :high(+32000); my @population :low(1900) :high(2039); $population[1923] = 323000; How about my @population[1900:2039]; Looks funny though. I'm quite fond of the idea of negative array indices. But don't you touch my precious C: operator, or I'll send in the hounds! I want its sanctity recognised for the purpose of the notation in RFC 81: http://tmtowtdi.perl.org/rfc/81.pod PS: Do you ever get the impression that some people will take every chance possible to segue all threads into a discussion of their own RFCs? ;-)
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? I guess it depends on what you think makes sense; but it seems to me that an array is a more fundamental data type; that it's easier (i.e. more efficient) to build associative arrays from arrays, than vice versa. -- John Porter
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 03:53 PM 8/15/00 -0400, John Porter wrote: Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? I guess it depends on what you think makes sense; but it seems to me that an array is a more fundamental data type; that it's easier (i.e. more efficient) to build associative arrays from arrays, than vice versa. It's silly to throw either of them out. Perl might be many things, but a reductionist language it ain't... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Dan Sugalski wrote: Generality good. For many things, yes. For computers, say. For people, no. Generality bad. Specificity and specialization good. People aren't generalists. They're a collection of specialists. The distinction is important. I'm sorry if I don't find this argument convincing. This argument suggests that *every* type carry a distinguishing prefix symbol -- including ones to distinguish between numbers and strings, say. Of course, you don't mean this. A balance must be struck. And while we're looking for the equilibrium, let's not prejudicially presume that "no symbols" is not an option. Even assuming highlander types, the punctuation carries a rather significant amount of contextual information very compactly. Yep. So, what's the gripe with it? Other than that it's not what you're used to, I mean. ...exploiting instinct and inherent capabilities give you faster response times, and quicker comprehension. Sure. But "instinct and inherent capabilities" do not apply here. -- John Porter Aus tiefem Traum bin ich erwacht.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 06:04 PM 8/15/00 -0400, John Porter wrote: Dan Sugalski wrote: Generality good. For many things, yes. For computers, say. For people, no. Generality bad. Specificity and specialization good. People aren't generalists. They're a collection of specialists. The distinction is important. I'm sorry if I don't find this argument convincing. This argument suggests that *every* type carry a distinguishing prefix symbol -- including ones to distinguish between numbers and strings, say. Numbers and strings really aren't different things, at least not as far as people are concerned. They are for machines, but computer languages ultimately aren't for machines, they're for people. Of course, you don't mean this. A balance must be struck. And while we're looking for the equilibrium, let's not prejudicially presume that "no symbols" is not an option. I'm not presuming that, though there are plenty of languages already that have no symbols. Perl's not one of them, though. Even assuming highlander types, the punctuation carries a rather significant amount of contextual information very compactly. Yep. So, what's the gripe with it? Other than that it's not what you're used to, I mean. It's going to always be more difficult. You need to *think* to turn a word into a symbol. = is already a symbol. Less effort's needed. ...exploiting instinct and inherent capabilities give you faster response times, and quicker comprehension. Sure. But "instinct and inherent capabilities" do not apply here. Yes, they do. People write source. People read source. People are the most important piece of the system. The computer can be made to cope with the syntax, whatever the syntax is. People can't be made to cope nearly as easily, nor to nearly the same degree. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? No, neither proposal makes sense. Arrays can be stored compactly and accessed and iterated through quickly, because they can take advantage of the fact that they are always indexed by an integer. You could remove the array/list data type and rely on Perl to try and implement hashes indexed by integers as a list, but that would introduce a lot of complexity for little real benefit.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote: Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? No, neither proposal makes sense. Arrays can be stored compactly and $a[1_000_000_000] = 'oh, really?' # :-) accessed and iterated through quickly, because they can take advantage of the fact that they are always indexed by an integer. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Array storage (was Re: RFC 84 (v1) Replace = (stringifying comma) with =)
Jarkko Hietaniemi wrote: On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote: Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? No, neither proposal makes sense. Arrays can be stored compactly and $a[1_000_000_000] = 'oh, really?' # :-) my int @a: sparse; $a[1_000_000_000] = 'Yes, really!' # :P OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute yet. My point is that arrays *can* be stored compactly, not that they always *are*. Another type of array storage is that required for lazily generated lists (see RFC 81) http://tmtowtdi.perl.org/rfc/81.pod
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 05:41 PM 8/15/00 -0500, Jarkko Hietaniemi wrote: No, neither proposal makes sense. Arrays can be stored compactly and $a[1_000_000_000] = 'oh, really?' # :-) Now, now, there have been credible proposals for sparse arrays, you know that... -- Peter Scott Pacific Systems Design Technologies
Re: Array storage (was Re: RFC 84 (v1) Replace = (stringifying comma) with =)
No, neither proposal makes sense. Arrays can be stored compactly and $a[1_000_000_000] = 'oh, really?' # :-) my int @a: sparse; I see: you have a time machine and I don't. So very unfair... $a[1_000_000_000] = 'Yes, really!' # :P OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute yet. My point is that arrays *can* be stored compactly, not that they always I smell...n-level bitmaps? *are*. Another type of array storage is that required for lazily generated lists (see RFC 81) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 84 (v1) Replace = (stringifying comma) with =
John Porter writes:
I think as long as equivalent (and better!) functionality is available,
through equivalently terse syntax, who's to care? Why is
$h{'foo'} = 'bar';
instrinsically preferable to
assoc( %h, 'foo', 'bar' );
I'm horrified you have to ask this question.
Perl makes easy things easy. Hashes are bloody useful, as the last
decade of Perl has borne out. They deserve syntactic support because
they're used a lot and are worthy of a shorthand.
Anybody who seriously suggests that something that is commonly used in
Perl should become *harder* (also aka longer to type) needs mental
realignment.
There are many bad ways to do things, and I think this is one of them.
Nat
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Lightning flashed, thunder crashed and Dan Sugalski [EMAIL PROTECTED] whispered: | Doesn't it make more sense to get rid of arrays and just use hashes? | | I guess it depends on what you think makes sense; but it seems to me | that an array is a more fundamental data type; that it's easier (i.e. | more efficient) to build associative arrays from arrays, than vice versa. | | It's silly to throw either of them out. Perl might be many things, but a | reductionist language it ain't... Why is it silly? Hashes and arrays are *conceptually* very similar (even if they are extremely different implementation-wise). One of them has implicit key, the other has an explicit key. They both provide some sort of ordered collection (plural), even if it is difficult to understand what the order is of hashes. Seems to me we could eliminate arrays and just keep hashes. We could promote "=" to be a key/value constructor while elements that don't have the "=" use a sequential number. Think of it like this: # Example "array" %array = qw/foo bar blah blech/; # Same thing, but explicit, a hash %array = (0 = "foo", 1 = "bar, 2 = "blah", 3 = "blech"); # A combination using implicit values %hash = (fn = "Bob", ln = "Smith", 10, 15, age = 35); # Same thing, using explicit %hash = (fn = "Bob", ln = "Smith", 0 = 10, 1 = 15, age = 35); -spp
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Stephen P. Potter writes: Why is it silly? Hashes and arrays are *conceptually* very similar (even if they are extremely different implementation-wise). If that were the case, I think students would have an easier time grasping hashes. It seems very common (yes yes, you all got them immediately, but merely by piping up and saying so, you do not invalidate my point, so please don't) that beginners take a long time to use hashes because they find them hard to get their heads around. This isn't why it's silly, just a comment on the idea that hashes and arrays are conceptually very similar. # Same thing, using explicit %hash = (fn = "Bob", ln = "Smith", 0 = 10, 1 = 15, age = 35); I have never wanted this kind of structure. It seems a ridiculous data structure to want. Keys are almost always heterogeneous in my world. I like Perl being able to optimize internally based on my simple one-character data typing (%). What are you trying to make easy with this? Nat
Re: Array storage (was Re: RFC 84 (v1) Replace = (stringifying comma) with =)
Dan Sugalski wrote: At 05:55 PM 8/15/00 -0500, Jarkko Hietaniemi wrote: No, neither proposal makes sense. Arrays can be stored compactly and $a[1_000_000_000] = 'oh, really?' # :-) my int @a: sparse; I see: you have a time machine and I don't. So very unfair... Need to upgrade to that new machine with the Pentium UltraMegaPro IV 2000 processor. (Now with thiotimoline! :) $a[1_000_000_000] = 'Yes, really!' # :P OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute yet. My point is that arrays *can* be stored compactly, not that they always I smell...n-level bitmaps? Nah, you smell vapor. The shapes in the vapor may well be n-level bitmaps, though. (Or possibly hashes with fixed keys optimized for integer key hashing for *real* sparse arrays...) The shape and feel of the vapor will be described in the RFC. The actual chemical makeup of the vapor will not.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Piers Cawley wrote:
$ints_from = ^1 = sub {$ints_from-(^1+1)};
$ints = $ints_from-(1);
I think pairs should use array range syntax ".." and be folded
into the array generator RFC (or at least referenced in that RFC).
In particular, using a pair in an array context should interpret
the pair as a sequence -- just like generated arrays.
my $pair = 1..4;
key $pair == 1
value $pair == 4
@{$pair} == (1, 2, 3, 4)
my $list = 1..2..3..nil;
key $list == 1
value $list == 2..3..nil
@{$list} == (1, 2, 3)
Of course in array context these would be lazily generated, i.e. streams.
For complex generated arrays, the left or right hand side of the pair
can be a bounding object which might have a generator function or step
value.
That's three special cases for turning a pair into a stream, but at
least it confines all this new magic to a single place in the language.
I think the idea that = is "just another comma" is pretty widespread
now.
BTW, regardless of whether = or .. are used, the operator has to be
right associative with low precedence. 1..2..3 should be 1..(2..3) and
not (1..2)..3. 1..$a+b..$d*e should be 1..(($a+b)..($d*e)).
Assignments to (key $pair) and (value $pair) should also do the right
thing and replace the key and value in the pair.
The use of = for named parameters IMHO is very distinct from pairs and
should be an implementation detail.
- Ken
P.S. I think it's funny that this RFC proposes a head and tail function
that are nearly as obscure as Lisp's car and cdr.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
I think the idea that = is "just another comma" is pretty widespread
now.
Just for the record I've always thought this was stupid. That's just my
opinion, true, but there's a fine line between TMTOWTDI and pure
confusion.
IMO, if you're going to have a different operator, make it do something
different. Especially something as stand-out as =, which many people
confuse with - already.
What I'd like to see this RFC say instead of/in addition to the PAIR
idea is that = can be used to create hashrefs without having to have
{}. So these two would be equivalent:
@foo = ( { one = two }, three, four );
@foo = ( one = two, three, four );
I know, I know, the = doesn't really have anything todo with how hashes
are built. However, its widespread use in this syntax sure makes people
think it does.
This wouldn't change the key/value idea, you could still get to the data
with it:
$foo = $key = $value;
$foo-{$key}; # $value
key $foo; # $key
value $foo;# $value
# these are the same
value $foo = $value2;
$foo-{$key} = $value2;
# what key does is rename the existing key
key $foo = $key2; # like delete $foo-{$key}, then
# $foo-{$key2} = $value
Or something like that. The RFC touches on this, but I think it should
just go all the way and make = into its own operator.
-Nate
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Peter Scott [EMAIL PROTECTED] writes:
At 07:29 PM 8/10/00 -0700, Glenn Linderman wrote:
Thanks for the clarification in your intentions, but isn't _any_ bareword is
converted to a string, unless it is in some particular context where a
bareword is
meaningful (such as filehandle)? So that seems to be nothing unique to
=. You
could just as well say
bareword, $whatever
and get the same effect in perl5!
Have you used strict lately? :-)
It also matters in this case:
sub bareword { }
foo(bareword,4);
vs
foo(bareword = 4);
--
Nick Ing-Simmons
Re: RFC 84 (v1) Replace = (stringifying comma) with =
=head1 TITLE
Replace = (stringifying comma) with = (pair constructor)
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 10 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 84
I like this a lot, especially the way it deals with subroutine
parameters.
But... would it be possible to exten this proposal so that, if the right
hand operand is an array or hash variable, it will create a reference to
this variable?
That would allow subroutine calls like:
foo('names' = @names, 'size' = 'A4', 'labels' = %labels)
to do the Right Thing. It would even make the CGI.pm interface easier
for newbies...
Hildo
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Thu, 10 Aug 2000 17:59:52 -0700, Glenn Linderman wrote: I find nothing in the documentation that suggests that = is anything other than a plain comma operator, yet you call it a "first-argument-stringifying comma operator". In fact, the documentation explicitly claims "=" is a synonym of "," (see perldata). I wonder what old version of the docs you are using. My perldata says: The `=' operator is mostly just a more visually distinctive synonym for a comma, but it also arranges for its left-hand operand to be interpreted as a string--if it's a bareword that would be a legal identifier. Calling "=" a synonym for "," is not the whole truth. It ignores the presence of the word "mostly" in that sentence, for one. -- Bart.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Thu, Aug 10, 2000 at 10:21:37PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace = (stringifying comma) with = (pair constructor)
=head2 Pairs and arrays
When a pair reference is assigned (in)to an array, it remains a single scalar
(referential) value. So:
@array = ( a=1, b=2, 'c', 3 );
assigns four elements (not six) to @array.
But won't this cause breakage to existing scripts
=head2 Pairs and subroutines
When a pair reference is used in the argument list of a subroutine with
no parameter list, it is passed as a single scalar value (i.e it remains
a pair reference).
When a pair reference is passed to a subroutine with named parameters, it
binds its value to the parameter of the same name, regardless of the order
in which it is passed.
Thus:
use Data::Dumper;
sub no_params {
print "no_params:\n"
print join "\n", map {ref||"scalar val"} @_;
print Dumper @_;
}
sub params ( $name, $rank, $serial_num) {
print "params:\n"
print join "\n", map {ref||"scalar val"} @_;
print Dumper @_;
}
no_params(serial_num=1234, name='demo', rank='RFC');
params(serial_num=1234, name='demo', rank='RFC');
prints:
no_params:
PAIR
PAIR
PAIR
$VAR1 = ( 'serial_num' = 1234 );
$VAR2 = ( 'name' = 'demo' );
$VAR3 = ( 'rank' = 'RFC' );
params:
scalar val
scalar val
scalar val
$VAR1 = 'demo';
$VAR2 = 'RFC';
$VAR1 = 1234;
Note that these semantics still support the popular:
sub hash_like_args {
my %args = @_;
# etc.
}
But they will break the idiom of
sub list_of_op_value_parameters {
while(my($op,$value) = splice(@_,0,2)) {
# process
}
}
list_of_op_value_paramaters(add = $v1, replace = $v2, add = $v3);
Graham.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Fri, Aug 11, 2000 at 11:24:48AM +1000, Damian Conway wrote:
This can be correctly handled. The named parameter's context specifier
would be propagated to the right operand of the =. So:
sub demo ( $name, \%options ) {...}
will accept:
demo(options=%myopts, name='my name');
but in the case of
sub demo ($name, %options) {...}
what does
demo($var, name = $value);
do ?
Graham.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
"Glenn" == Glenn Linderman [EMAIL PROTECTED] writes:
Glenn No, but the documentation for strict is some of what I reread
Glenn before making a fool of myself arguing with Damian, and it says
Glenn nothing about barewords, as far as I could read.
Even this part? ...
strict subs
This disables the poetry optimization, generating a
compile-time error if you try to use a bareword
identifier that's not a subroutine, unless it
appears in curly braces or on the left hand side of
the "=" symbol.
use strict 'subs';
$SIG{PIPE} = Plumber; # blows up
$SIG{PIPE} = "Plumber"; # just fine: bareword in curlies always ok
$SIG{PIPE} = \Plumber; # preferred form
Looks pretty direct to me. Maybe that was further than you could
read? :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Fri, 11 Aug 2000 11:01:30 -0400 (EDT), Simply Hao wrote: What about with -w: read = $value What warning? Oh, you're probably using a pre-5.005 Perl. 5.004 (the latest MacPerl, for example) still had that warning. 5.005 and later, do not, any more. -- Bart.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
I kinda like it. It's... intuitive. It makes named sub arguments rather
straightforward, apart from that prefix thing.
Should (name = 'Bart') really stuff 'Bart' into a lexical variable
$name? That's... odd.
Not really. If (name='Bart') is an arg list, it probably stuffs 'Bart' into
a lexical variable already (via an explicit Cmy %args = @_).
I see no connection between 'name' and '$name', but I'm trying
really hard to ignore any similarities.
They're more alike that name and $args{name}, and people cope with that.
They're more alike that *{name}{SCALAR} and \${name}, and (some) people
cope with that too.
You have overlooked one reference: RFC 21, "Replace Cwantarray with a
generic Cwant function", by... you. :-) I understand that a pair would
behave differently in array context (may I call it that?) than in a hash
context.
That's not how I think of it.
The difference is how a hash and an array *interpret* a PAIR that's assigned to
them. The hash unwraps the pair and stores the value under the key. Teh array
just stores the PAIR as a reference (as it would any other type of reference).
What about the current habit of passing arguments using the "-bareword
= $value" syntax, to unprototyped subs? Is this an array or a hash
context? Or does it not matter?
The distinction doesn't exists, so it (probably) doesn't matter :-)
In case you're wondering, I am thinking
about backward compatibility of current modules on CPAN that use this
syntax, whether these would still work under Perl6, or whether they'd
need a rewrite. (ugh!)
p52p6 would handle it (by translating all Perl 5 Cx="y"'s to Perl 6
C'x',"y"'s.
I *must* put this in the RFC!
Damian
Re: RFC 84 (v1) Replace = (stringifying comma) with =
@array = ( a=1, b=2, 'c', 3 );
assigns four elements (not six) to @array.
But won't this cause breakage to existing scripts
No. p52p6 will simply translate:
x = 'y'
to
'x', 'y'
Note that these semantics still support the popular:
sub hash_like_args { my %args = @_; }
But they will break the idiom of
sub list_of_op_value_parameters {
while(my($op,$value) = splice(@_,0,2)) {
# process
}
}
The abovemention translation will cover this too.
Damian
Re: RFC 84 (v1) Replace = (stringifying comma) with =
But... would it be possible to exten this proposal so that, if the right
hand operand is an array or hash variable, it will create a reference to
this variable?
That would allow subroutine calls like:
foo('names' = @names, 'size' = 'A4', 'labels' = %labels)
to do the Right Thing.
Did you see my other post on context propagation of \@ and \% contexts
into the right operand slot? I think that solves the problem too.
But I'll certainly think about your suggestion.
Damian
Re: RFC 84 (v1) Replace = (stringifying comma) with =
[EMAIL PROTECTED] writes: : p52p6 would handle it (by translating all Perl 5 Cx="y"'s to Perl 6 : C'x',"y"'s. : : I *must* put this in the RFC! I think most of the RFCs could use a MIGRATION POLICY section, or some such. Larry
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Nathan Wiger wrote: ...if the "key" and "value" builtins were the only ways to get to the data. You should be able to get to the data directly. How about: $array[0].k $array[0].v -- John Porter
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Damian Conway [EMAIL PROTECTED]:
This RFC proposes the introduction of a new data type -- the Ipair -- and
the co-opting of the = operator to act as a pair constructor. Most existing
uses of = would be preserved.
[etc.]
%hash = ( a=1, b=2, 'c', 3 );
does what it does in Perl 5, but works slightly differently.
Yeah; so what's the point? Will hashes being represented internally
as sets of pairs be somehow more efficient? What's the win?
When a pair reference is assigned (in)to a hash, the pair's key becomes
the hash entry's key, and the pair's value becomes the entry's value
Wasn't there talk of allowing types other than scalars to be hash keys?
If so, then a pair could not be a hash key, except in the singular
assignment
$hash{ $pair } = $val;
but not in something as trivial as
%hash = ( $pair, $val, $pair2, $pair3 );
I could make a more trivial example, but then I expect you to say
that hash assignment will be smarter about inferring an even number
of values in the rhs.
=head2 Pairs and multiway comparisons
Pairs also provide a clean way of implementing multiway comparisons.
It is proposed that when a pair is evaluated in a boolean context, it
would evaluate to the truth value of its key. But when evaluated as the left
operand of a comparison operator, it would evaluate to its value,
Ibut would short-circuit if its key were false.
Has anyone checked how Icon does this?
(Yeah, I know, I should do it myself.)
Here's a counter-proposal: throw out hashes as a separate internal
data type, and in its place define a set of operators which treat
(properly constructed) arrays as associative arrays. It's the
operators that do all the work anyway; the semantic benefit of
a distinct data type is miniscule. And away with pairs: use
arrays instead. Perhaps, along with constant scalars, we should
be able to declare arrays as having a constant size; and a "pair"
would be a predefined alias for "array with constant size = 2".
One benefit is this allows any type to be the "key" of an assoc. array,
with no extra support required in the core; deep and special-case
comparisons can be supplied by the user.
--
John Porter
Aus tiefem Traum bin ich erwacht.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
On Fri, 11 Aug 2000 15:27:03 +0200, Bart Lateur wrote: I kinda like it. I'm not sure any more if I still like it as much. As proposed, it seems very unperlish (as we know Perl today). It would virtually turn Perl into a whole different language. Well, half a different language. ;-) I, too, have a counterproposal, although very sketchy. Imagine that = automagically "blesses" the scalar on the left, as "this item has been marked as the key of a pair". It could be even just one flag bit in the scalar descriptor, or such. Scalars would still be scalars, and in assignment to arrays: @array = ( a=1, b=2, 'c', 3 ); @array would still have 6 items. But, in this example, both the 'a' and the 'b' would still be marked as a pair key, and somesub(@array); would do the automagic thing, as if the above expression was used directly. All in all, I think it would be a far less intrusive change, while still maintaining most of the advances. Wouldn't it? I don't know about the multiway comparisons. The value "zero but true", while still being represented by the string "0", looks... strange. For a scalar, at least. -- Bart.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
I guess I shouldn't use printed docs for anything in these discussions. I looked that up on paper, and it really does (did) say "synonym". But things change. I'd tell you what version of paper I looked it up on, but the paper doesn't seem to have recorded its version number. Perl 5.something. Probably pretty early. Perhaps the printed docs should preserve their version, starting with perl6 (or earlier)... just to remind one of their age... Bart Lateur wrote: On Thu, 10 Aug 2000 17:59:52 -0700, Glenn Linderman wrote: I find nothing in the documentation that suggests that = is anything other than a plain comma operator, yet you call it a "first-argument-stringifying comma operator". In fact, the documentation explicitly claims "=" is a synonym of "," (see perldata). I wonder what old version of the docs you are using. My perldata says: The `=' operator is mostly just a more visually distinctive synonym for a comma, but it also arranges for its left-hand operand to be interpreted as a string--if it's a bareword that would be a legal identifier. Calling "=" a synonym for "," is not the whole truth. It ignores the presence of the word "mostly" in that sentence, for one. -- Bart. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Piers Cawley [EMAIL PROTECTED] writes:
Damian Conway [EMAIL PROTECTED] writes:
Are the two values of a pair restricted in anyway? All your examples
were scalar.
Yes. The two components must be scalars.
The key is stringified iff it's a bareword.
Otherwise no restrictions.
So assuming pairs are scalars...
[...]
How about:
(a = b = (c = d = e) = f = g)
Maybe we could have a pragma:
use lisplike;
Which would make
(a b (c d e) f g) == (a = b = (c = d = e) = f = g)
Hmm... you know, once more I'm not sure if this is ugly or beautiful,
but it's certainly fascinating. I think I like it.
Ooh, and we could use 'em for streams as well...
$ints_from = ^1 = sub {$ints_from-(^1+1)};
$ints = $ints_from-(1);
Now, if that hasn't sent the lisp haters running, screaming to the
hills, I wonder what will...
--
Piers
RFC 84 (v1) Replace = (stringifying comma) with =
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace = (stringifying comma) with = (pair constructor)
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 10 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 84
=head1 ABSTRACT
This RFC proposes the introduction of a new data type -- the Ipair -- and
the co-opting of the = operator to act as a pair constructor. Most existing
uses of = would be preserved.
=head1 DESCRIPTION
It is proposed that a new data structure, to be known as a Ipair, be
added to the language. The = operator would cease to be a
first-argument-stringifying comma operator, and becomes an anonymous pair
constructor (just as [...] and {...} are anonymous list and hash constructors
respectively). The = operator would return a reference to a pair containing
the two operands to =.
The first component of a pair would be called its Ckey, and the second, it's
Cvalue. It is proposed to either extend the semantics of Ckeys and
Cvalues to allow them to operate of pair references, or else introduce
two new built-ins -- Ckey and Cvalue -- to access the components of a pair.
=head2 Pairs and hashes
A hash could be constructed from a list of pair references. In fact a
hash could be thought of (and perhaps implemented!) as a set of pairs.
Thus:
%hash = ( a=1, b=2, 'c', 3 );
does what it does in Perl 5, but works slightly differently. The list being
assigned consists of four elements (not six): a pair reference, another pair
reference, a string, and an integer.
When a pair reference is assigned (in)to a hash, the pair's key becomes
the hash entry's key, and the pair's value becomes the entry's value
As the above example indicates, hashes could still be assigned "flat" lists.
=head2 Pairs and arrays
When a pair reference is assigned (in)to an array, it remains a single scalar
(referential) value. So:
@array = ( a=1, b=2, 'c', 3 );
assigns four elements (not six) to @array.
=head2 Pairs and subroutines
When a pair reference is used in the argument list of a subroutine with
no parameter list, it is passed as a single scalar value (i.e it remains
a pair reference).
When a pair reference is passed to a subroutine with named parameters, it
binds its value to the parameter of the same name, regardless of the order
in which it is passed.
Thus:
use Data::Dumper;
sub no_params {
print "no_params:\n"
print join "\n", map {ref||"scalar val"} @_;
print Dumper @_;
}
sub params ( $name, $rank, $serial_num) {
print "params:\n"
print join "\n", map {ref||"scalar val"} @_;
print Dumper @_;
}
no_params(serial_num=1234, name='demo', rank='RFC');
params(serial_num=1234, name='demo', rank='RFC');
prints:
no_params:
PAIR
PAIR
PAIR
$VAR1 = ( 'serial_num' = 1234 );
$VAR2 = ( 'name' = 'demo' );
$VAR3 = ( 'rank' = 'RFC' );
params:
scalar val
scalar val
scalar val
$VAR1 = 'demo';
$VAR2 = 'RFC';
$VAR1 = 1234;
Note that these semantics still support the popular:
sub hash_like_args {
my %args = @_;
# etc.
}
hash_like_args(serial_num=1234, name='demo', rank='RFC');
=head2 Pairs and multiway comparisons
Pairs also provide a clean way of implementing multiway comparisons.
It is proposed that when a pair is evaluated in a boolean context, it
would evaluate to the truth value of its key. But when evaluated as the left
operand of a comparison operator, it would evaluate to its value,
Ibut would short-circuit if its key were false.
Thus:
1 4 7 9
would be evaluated:
(((1 4) 7) 9)
(((true=4) 7) 9) # true because 1 4
((true=7) 9) # true because 4 7
(true=9) # true because 7 9
1 # boolean context evals to truth of key
On the other hand:
1 4 7 3 9
would be evaluated:
1 4) 7) 3) 9)
true=4) 7) 3) 9) # true because 1 4
(((true=7) 3) 9) # true because 4 7
((''=3) 9) # '' (false) because !(7 3)
'' # short circuits to false
=head1 REFERENCES
Forthcoming Conway RFC on subroutine parameter lists
(including named parameters)
RFC 25: Operators: Multiway comparisons
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Perl6 RFC Librarian wrote: [...] This RFC proposes the introduction of a new data type -- the Ipair [...] I hereby propose that all current Perl 6 Project Plan deadlines be extended 3 months so that Damian has more time to come up with gems like this. I have no idea if it ultimately makes sense or will be implemented or just how it would be used, but it's damn intriguing.
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Damian Conway wrote: When a pair reference is assigned (in)to an array, it remains a single scalar (referential) value. So: @array = ( a=1, b=2, 'c', 3 ); assigns four elements (not six) to @array. The proposed Ckey and Cvalue built-ins (or the extended Ckeys and Cvalues) would be used on a pair reference: print key $array[0];# or perhaps: print keys $array[0]; ^^^ Makes sense Mismatch ^ ^ print value $array[0]; # or perhaps: print value $array[0]; ^ 's' But what does Ckey $array[2] do? Or Ckeys @array? Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Shades of LISP, batman. tongue in cheek I can see it now, the '=' operator will be called cons-ing. And the new keword for accessing a pair will be CAR and CDR. /tongue in cheek Are the two values of a pair restricted in anyway? All your examples were scalar. What about a plural whatzit or a reference to a plural whatzit? chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL =head1 ABSTRACT PRL This RFC proposes the introduction of a new data type -- the Ipair -- and PRL the co-opting of the = operator to act as a pair constructor. Most existing PRL uses of = would be preserved. PRL =head1 DESCRIPTION PRL The first component of a pair would be called its Ckey, and the second, it's PRL Cvalue. It is proposed to either extend the semantics of Ckeys and PRL Cvalues to allow them to operate of pair references, or else introduce PRL two new built-ins -- Ckey and Cvalue -- to access the components of a pair. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Are the two values of a pair restricted in anyway? All your examples were scalar. Yes. The two components must be scalars. The key is stringified iff it's a bareword. Otherwise no restrictions. What about a plural whatzit or a reference to a plural whatzit? References are fine. Arrays and hashes are not. Damian
Re: RFC 84 (v1) Replace = (stringifying comma) with =
I find nothing in the documentation that suggests that = is
anything other than a plain comma operator, yet you call it a
"first-argument-stringifying comma operator". In fact, the
documentation explicitly claims "=" is a synonym of "," (see
perldata).
The Perl documentation contains only a second approximation to Perl. :-)
The perl interpreter contains the first approximation.
(For those who are wondering: Larry's brain contains the zero'th approximation)
So I'm curious where you get this from,
From the fact that = currently converts any bareword left operand to a string.
and what you mean by it,
That = currently converts any bareword left operand to a string.
and whether it is relevant to this RFC.
Yes, because it's proposed that this aspect of ='s behaviour be preserved.
Note that these semantics still support the popular:
[SNIP]
But not the (safer) alternative:
[SNIP]
Sure they do. p52p6 would handle the change in semantics by mapping
every Perl 5 instance of:
bareword = $whatever
to:
'bareword', $whatever
and every remaining instance:
$non_bareword = $whatever
to:
$non_bareword, $whatever
With an appropriate prototyping system, perhaps pairs would be
useful for named scalar arguments to subs. Quite a few have
complained about missing the $ in other named parameter proposals
though,
And they're wrong. :-)
The variables *shouldn't* appear in the calling scope, only their *names*.
and pairs neither help that, nor provide help for passing
arrays or hashes by name.
This can be correctly handled. The named parameter's context specifier
would be propagated to the right operand of the =. So:
sub demo ( $name, \%options ) {...}
will accept:
demo(options=%myopts, name='my name');
because the C\% prototype for the parameter \%options will be
propagated to the right operand of Coptions=%myopts, causing it
to act like Coptions=\%myopts.
Damian
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Glenn Linderman wrote: Thanks for the clarification in your intentions, but isn't _any_ bareword is converted to a string, unless it is in some particular context where a bareword is meaningful (such as filehandle)? So that seems to be nothing unique to =. You could just as well say bareword, $whatever and get the same effect in perl5! Except that that doesn't work under 'use strict', whereas = does. Also, under '-w' the ',' form gives an 'Unquoted string' warning. So the operators really are subtly different.
