Re: a modest proposal Re: s/./~/g
I just want to say it seems appropriate that this discussion of how Perl can look like Morse Code is happening in the thread I first started, since I was active in ham radio from 1970-95 (mostly CW, or Morse Code to you non-hams). And consider it a blessing that Perl can look like Morse Code, not line noise :) phred ex-W3XY
Re: a modest proposal Re: s/./~/g
On Sat, Apr 28, 2001 at 10:39:01AM -0700, Larry Wall wrote: Now we just need to make ... ___ ... mean something exceptional. ___ ... ___ is valid. :) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One BOFH excuse #437: crop circles in the corn shell
Re: a modest proposal Re: s/./~/g
Larry Wall wrote: Now we just need to make ... ___ ... mean something exceptional. Ref: http:[EMAIL PROTECTED]/msg02873.html ) -- John Porter
Re: a modest proposal Re: s/./~/g
Simon Cozens writes: : Hey, that would make _ _ __ legal Perl code. Abigail, Abigail! Now we just need to make ... ___ ... mean something exceptional. : (I still prefer ~, but acknowledge that this is just bikeshed painting.) Bikesheds need to be painted occasionally. Larry
Re: a modest proposal Re: s/./~/g
: Hey, that would make _ _ __ legal Perl code. Abigail, Abigail! Now we just need to make ... ___ ... mean something exceptional. Just download the Bleach.pm module from the CPAN. It includes Morse.pm. Damian ---cut---cut---cut---cut---cut-- use Morse; .--.-..--..---.-.--..--.-..--..---.-.--. .-.----..-..---.-..-.--..---.--. ..-.---..-...-...-..--..-.-.-.--.-.. ..-.-.--.-..--..-.-...---.-..---.--. .-...-..--.---...-.-
Re: a modest proposal Re: s/./~/g
On Thu, Apr 26, 2001 at 04:46:48PM -0700, Larry Wall wrote: And I'm tired of hearing the argument that Perl programmers can't get used to a different operator for concatenation. I know better--after all, Perl is probably what got them used to . in the first place. If you can teach dogs to salivate at a bell, you can probably teach them to salivate at a dog biscuit. :-) I think many of us are resigned to losing . for concatination; I know I can live with that. I just don't want to have this result in ~, ^, or any other C-style punctuation operator getting renamed. I like the fact that Perl follows the same operator conventions as C, C++, Java and others in this area; breaking with tradition here for the sake of aligning . feels inelegant. Renaming . to cc wouldn't bother me half so much. - Damien
Re: a modest proposal Re: s/./~/g
On Fri, Apr 27, 2001 at 01:45:02AM -0700, Damien Neil wrote: I think many of us are resigned to losing . for concatination; I know I can live with that. I just don't want to have this result in ~, ^, or any other C-style punctuation operator getting renamed. That's my position. I'd rather live without a concatenation operator than use ~ or ^ for it. But if we must have a concatenation operator, I'd rather it be cc or _ (I didn't like the underscore at first, but it's grown on me a little) or some other punctuation that doesn't already have some well-established-across-multiple-languages meaning. anyway, my two cents ... -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: a modest proposal Re: s/./~/g
Jonathan Scott Duff wrote: I'd rather it be cc or _ (I didn't like the underscore at first, but it's grown on me a little) Comparing ~ and _ to available editors markup marks, _ is closer to the sideways () that an editor might use to indicate that two words should be joined together. Tilde looks like it might mean switch the order of the token ahead and the token behind me Will there be confusion with the _ that means the file statted by the last -X test? I doubt it: file tests need to bind tighter than the concat op and the problem is over. I can't create a situation where it would be confusing anyway -- what would the LHS of the _ be in a test situation? There wouldn't be one. For that matter, indirect object syntax is always bareword $object|bareword argument[, ...] which would collide with relatively few concat accretions, even without any semantic information. If it starts with a bareword, it's not a concat. A stronger argument against white-space-juxtapositions IMO would be the possible confusion generated by arguments getting accretted when a comma gets left out, instead of a syntax exception getting thrown: function(this,that the other); the second argument is now the intended second and third args and there is no third arg, instead of a syntax error. -- David Nicol 816.235.1187 [EMAIL PROTECTED] and they all say yodelahihu
Re: a modest proposal Re: s/./~/g
On Wed, 25 Apr 2001 18:19:40 GMT, Fred Heutte wrote: Yes, I know ~ is the bitwise negation operator. Have you EVER used it? Yes. A lot. But there is no conflict. ~ is currently just an unary operator, while your use would be as a binary operator (are those the correct terms?). For example, in -3.4 and in 2-3.4 the - sign is a *different* kind of operator. No conflict. -- Bart.
Re: a modest proposal Re: s/./~/g
Bart Lateur's response summarizes well what I've heard so far from responses both to the list and privately: (1) Yes, ~ *is* somewhat used in its current role as the bitwise negation (complement) operator. (2) No, that doesn't appear to overlap my proposal for its use as a successor to - as now used. Another cheer for the principle of least disturbance from the Laziness SIG...
Re: s/./~/g
Fred Heutte [EMAIL PROTECTED] writes: A vote against the proposed switches, for an unbearably lazy (ok, selfish) reason. Having to use the shift key with any non-alphanumeric keypress always feels like a lot of extra work. This is why I have long avoided underscores in variable names. (This is the same reason I avoid = which not only adds another keystroke beyond , but also has the dreaded punctuation-key-shift. I'm not arguing this is *better*, just more convenient for me personally. Or maybe it's just that I prefer not to hang around too much with shifty characters.) The 'fat-comma' actually saves keystrokes and looks good for creating paired data. From perlop: The = digraph is mostly just a synonym for the comma operator. It's useful for documenting arguments that come in pairs. As of release 5.001, it also forces any word to the left of it to be interpreted as a string. Having used . for string concats for 10 years, I could adjust to ~ but good golly is that annoying. Also it does detract from readability a little. $a = my . $strings . join(@together) ; $a = my ~ $strings ~ join(@together) ; Actually using a period to mean push these things together rather than full-stop always seemed odd to me. I use the concat operator very rarely. I would write the above: $a = my $strings @together; (You weren't careful about spaces, but you need to be when using concat. String interpolation is easier to get right the first time. Also I don't think your join is what you want.) If I had to choose between . and ~, I'd take the tilde. I wouldn't mind if it went away altogether, however -- I only use it to simulate function interpolation: $prompt = scalar(getpwuid $) . \n\$ ; I'd rather write: $prompt = scalar(getpwuid $)\n\$ ; I don't mind ~ as the binding operator. It makes me go slower and think, aha! drive carefully: $throttle =~ s/regex ahead/downshift brain/ ; Jon
Re: a modest proposal Re: s/./~/g
Nathan Wiger writes: : Now, it may be that all the We should use . people are just keeping : quiet, or think it's obvious why this is a benefit, but I'm unconvinced. : Again, I'm open-minded, but the only argument I've really heard is to : make Perl more Java/Python-like. This doesn't sway me at all. Are there : other reasons? Yes, there are, but I don't really want to write Apocalypse 12 before I finish Apocalypse 2. However, I can tell you that object attributes will likely be declared as special variables within a class like this: my $.foo; my @.bar; my %.baz; and henceforth be usable as either methods or as data values (but the latter only within the object methods of the class). It is also a distinct possibility that unary . will be used to indicate methods called on the current object. This would avoid both the problems of trying to come up with an agreed-upon name for $self/$this/self/me/whatever, but also avoid the problem of C++ where a method call is not visually distinguished from a function call. Anyway, I wish you folks would stop arguing about heroic measures to rescue the . operator for concatenation. It's not going to happen. I want people to associate .foo with the idea of methods and attributes about the way they associate $foo with scalars currently. This won't happen if we overload it, and I'm pretty picky when it comes to the psychology of the thing. And I'm tired of hearing the argument that Perl programmers can't get used to a different operator for concatenation. I know better--after all, Perl is probably what got them used to . in the first place. If you can teach dogs to salivate at a bell, you can probably teach them to salivate at a dog biscuit. :-) Larry
Re: a modest proposal Re: s/./~/g
On Thu, Apr 26, 2001 at 03:35:24AM +, Fred Heutte wrote: Bart Lateur's response summarizes well what I've heard so far from responses both to the list and privately: (1) Yes, ~ *is* somewhat used in its current role as the bitwise negation (complement) operator. (2) No, that doesn't appear to overlap my proposal for its use as a successor to - as now used. You don't get it. We are not looking for a single char to replace - We WANT to use . Graham.
Re: s/./~/g
A vote against the proposed switches, for an unbearably lazy (ok, selfish) reason. Having to use the shift key with any non-alphanumeric keypress always feels like a lot of extra work. This is why I have long avoided underscores in variable names. (This is the same reason I avoid = which not only adds another keystroke beyond , but also has the dreaded punctuation-key-shift. I'm not arguing this is *better*, just more convenient for me personally. Or maybe it's just that I prefer not to hang around too much with shifty characters.) Having used . for string concats for 10 years, I could adjust to ~ but good golly is that annoying. Also it does detract from readability a little. $a = my . $strings . join(@together) ; $a = my ~ $strings ~ join(@together) ; I don't mind ~ as the binding operator. It makes me go slower and think, aha! drive carefully: $throttle =~ s/regex ahead/downshift brain/ ; Fred
Re: a modest proposal Re: s/./~/g
Graham Barr wrote: You don't get it. We are not looking for a single char to replace - We WANT to use . With complete respect here, I'm still not convinced this is true. Specifically, what the value of we is. It hardly sounds like everyone's united on this point. In fact, I've counted more postings of the tone Why would we change - ?! than the other way around. Now, it may be that all the We should use . people are just keeping quiet, or think it's obvious why this is a benefit, but I'm unconvinced. Again, I'm open-minded, but the only argument I've really heard is to make Perl more Java/Python-like. This doesn't sway me at all. Are there other reasons? -Nate
Re: s/./~/g
Eric Roode wrote: What is it about . that seems to inspire allergic reactions in people? Surely it's not the . itself, but the requirement that you fit everything into that one syntactic mold. Perl's not going to do that. No, more like . is already used for something. The only reason I have seen written out so far for the shift from - to . and . to insert op here is: it looks more like other languages. That seems like a whole lot of fixing of non-broken syntax. which is why, back in http://www.mail-archive.com/perl6-all%40perl.org/msg01043.html Oh, last august, we discussed all this -- David Nicol 816.235.1187 [EMAIL PROTECTED] and they all say yodelahihu
a modest proposal Re: s/./~/g
It seems to me that ~ relates to forces (operators, functions and methods) more than to atoms (scalars), so to speak. It's the curve of binding Perl at work here. So why not leave . alone and have ~ substitute for - $mydsn-Sql($mysqlstmt . $moresql) ; $mydsn~Sql($mysqlstmt . $moresql) ; Yes, I know ~ is the bitwise negation operator. Have you EVER used it? Besides, as far as I can tell from a first-order look, the two meanings would not have to be rival (as in a different way \ for denoting a reference and \ for denoting an escaped byte are not). Fred
Re: a modest proposal Re: s/./~/g
On Wed, Apr 25, 2001 at 06:19:40PM +, Fred Heutte wrote: : It seems to me that ~ relates to forces (operators, functions and methods) : more than to atoms (scalars), so to speak. It's the curve of binding Perl : at work here. : : So why not leave . alone and have ~ substitute for - : : $mydsn-Sql($mysqlstmt . $moresql) ; : $mydsn~Sql($mysqlstmt . $moresql) ; In that case I'd rather use this syntax: $obj'attribute; $obj'constructor'method; Or... maybe not... -- Casey West
Re: a modest proposal Re: s/./~/g
On Wed, Apr 25, 2001 at 06:19:40PM +, Fred Heutte wrote: It seems to me that ~ relates to forces (operators, functions and methods) more than to atoms (scalars), so to speak. It's the curve of binding Perl at work here. So why not leave . alone and have ~ substitute for - $mydsn-Sql($mysqlstmt . $moresql) ; $mydsn~Sql($mysqlstmt . $moresql) ; Yes, I know ~ is the bitwise negation operator. Have you EVER used it? Yes, I use it a lot. Whether you use it probably depends on the kind of problems you try to solve with perl. Graham.
Re: s/./~/g
Larry Wall wrote:
Okay, but it's just as many characters to say - as it is \., y'know.
Yep. But I'll plead rule #1 for myself, and let it go.
(The other thought I had was that slashes might be nice, since
some filesystem hierarchies use it. But then the division op
gets squeeged.
Hm. Maybe by following the m// pattern, the component separator
could be locally user-settable.
Foo::Bar# the normal case
d./Foo.Bar/ # make it dot for the nonce. I mean hence.
d/[Foo/Bar] # make it slash.
d(-){Foo-Bar} # on second though... never mind.
)
method interpolations
are likely to require parentheses, even if there are no arguments.
Otherwise $file.ext is gonna break badly.
I expect to see a lot more parens and/or curlies in interpolations.
And frankly it won't bother me none. As long as $foo still works
without 'em -- and I know I don't need to worry about that.
--
John Porter
It's a sky-blue sky
The satellites are out tonight
let x = x
Re: s/./~/g
Branden [EMAIL PROTECTED] writes: 1) Use $obj.method instead of $obj-method : The big question is: why fix what is not broken? Why introduce Javaisms and VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 code (and Perl 5 programmers) for a zero net gain? $obj.method isn't a Java-ism; it's used by both C++ and by Simula (for class variables), and in C for struct members, which given the origins of those languages means I wouldn't be surprised if it were in Algol. The switch from - to . makes perfect sense from a C perspective if we're turning objects into first-class entities rather than pointers; think about a struct versus a pointer to a struct. - makes you remember that things are pointers. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: s/./~/g
On 24 Apr 2001, Russ Allbery wrote: Branden [EMAIL PROTECTED] writes: 1) Use $obj.method instead of $obj-method : The big question is: why fix what is not broken? Why introduce Javaisms and VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 code (and Perl 5 programmers) for a zero net gain? The switch from - to . makes perfect sense from a C perspective if we're turning objects into first-class entities rather than pointers; think about a struct versus a pointer to a struct. - makes you remember that things are pointers. What's wrong with using both? You could use - if you're working with a reference to an object, and you could use . if you're working with the object itself. - D [EMAIL PROTECTED]
Re: s/./~/g
David M Lloyd [EMAIL PROTECTED] writes: On 24 Apr 2001, Russ Allbery wrote: The switch from - to . makes perfect sense from a C perspective if we're turning objects into first-class entities rather than pointers; think about a struct versus a pointer to a struct. - makes you remember that things are pointers. What's wrong with using both? You could use - if you're working with a reference to an object, and you could use . if you're working with the object itself. It seems relatively unlikely in the course of normal Perl that you're going to end up with very many references to objects. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: s/./~/g
On 24 Apr 2001, Russ Allbery wrote:
David M Lloyd [EMAIL PROTECTED] writes:
What's wrong with using both? You could use - if you're working with a
reference to an object, and you could use . if you're working with the
object itself.
It seems relatively unlikely in the course of normal Perl that you're
going to end up with very many references to objects.
Well, right now in Perl, an object *is* a reference. In Perl 6, will that
always be the case? When talking about something like this:
@myarray.method;
Maybe you want to pass around a reference to @myarray because it contains
a billion elements, or is tied to a file, or something; in that case
(borrowing from p5) you'd have something C-ish like this:
@{$myarrayref}.method;
But doing this:
$myarrayref-method;
is a bit clearer. I don't know; I guess we don't know for sure how any of
this will fall out, but it makes some sense to me to do it this way.
Maybe I'll be quiet now. :-)
- D
[EMAIL PROTECTED]
Re: s/./~/g
At 06:34 AM 4/24/2001 -0700, Russ Allbery wrote: David M Lloyd [EMAIL PROTECTED] writes: On 24 Apr 2001, Russ Allbery wrote: The switch from - to . makes perfect sense from a C perspective if we're turning objects into first-class entities rather than pointers; think about a struct versus a pointer to a struct. - makes you remember that things are pointers. What's wrong with using both? You could use - if you're working with a reference to an object, and you could use . if you're working with the object itself. It seems relatively unlikely in the course of normal Perl that you're going to end up with very many references to objects. And even if you do, I can guarantee that within 10 minutes of starting code that does, you'll be cursing at perl. Why can't you just DWIM? you will curse. You should be able to figure out that reference is to an object! If you don't, I certainly will. ;) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: s/./~/g
On Tue, Apr 24, 2001 at 08:38:58AM -0500, David M. Lloyd wrote: Well, right now in Perl, an object *is* a reference. No. An object is a referent. Two blessed references can refer to the same data; however, that's only one object. -- teco /dev/audio - Ignatios Souvatzis
Re: s/./~/g
On Tue, 24 Apr 2001, Simon Cozens wrote: On Tue, Apr 24, 2001 at 08:38:58AM -0500, David M. Lloyd wrote: Well, right now in Perl, an object *is* a reference. No. An object is a referent. Two blessed references can refer to the same data; however, that's only one object. Oops, that's what I meant. :-) - D [EMAIL PROTECTED]
RE: s/./~/g
From: Russ Allbery [mailto:[EMAIL PROTECTED]]
David M Lloyd [EMAIL PROTECTED] writes:
On 24 Apr 2001, Russ Allbery wrote:
It seems relatively unlikely in the course of normal Perl
that you're going to end up with very many references to
objects.
Well, right now in Perl, an object *is* a reference.
Precisely. So there's almost never any reason to create a
reference to an object, which would be a reference to a
reference, and for those rare circumstances the existing
dereference syntax is probably adequate.
How many classes uses a flyweight scalar reference to work around circular
references in garbage collection? Class::Contract does. Also, if it is
common enough to be covered in the Perl Cookbook (13.13)... it probably
isn't too uncommon.
Class::Contract provides a generic constructor which returns a reference to
a reference.
my $key = \ my $undef;
my $obj = \ $key;
bless $obj, $class;
This is to avoid circular references while providing better encapsulation.
$obj is a flyweight reference to $key. Object attribute accessors lookup
object data in the Class::Contract lexical %data. There is no way to get at
an object's data except through the interface defined in the contract.
When the $obj goes out of scope, the Class::Contract provided destructor
deletes $data{$key}.
Now all that that means, is that it isn't uncommon that an object might be a
reference to a reference. It is up to the user to decide to make a reference
to that object. But I'd venture to guess that that isn't an all too uncommon
thing.
I would presume that objects will still be implemented as
references under the hood so that passing them around is
efficient no matter what they contain.
I guess that falls back into Branden's thread of tying variables vs.
overloading values. Which to me is overloading accessors vs. methods. When
someone overloads @foo to be an instance of Foo, is that tying per Perl 5:
magic variables which redirect variable accessors to a class... or something
new? I certainly hope magic in perl 6 is reincarnated as something much more
accessible at runtime to users.
Re: s/./~/g
Branden writes: : I'm starting to be a bit worried with what I'm reading... : : 1) Use $obj.method instead of $obj-method : : : The big question is: why fix what is not broken? Why introduce Javaisms and : VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 : code (and Perl 5 programmers) for a zero net gain? It's not zero net gain, and I'm going to ignore the next person who says it. : 2) Use $a~$b instead of $a.$b : : : The same argument, only stronger now. This one still poses another problem: : for $a = $a ~ $b, the syntax would be $a ~= $b. Now read these two quickly : and tell me what's the difference : : $a~=$b; : $a=~$b; : : It's not only hard to teach the =~ operator, imagine teaching that there : are two of them... Imagine if a programmer writes the wrong one, how long : you'll have to wade through that code until find the bug! We have lots of operators you wouldn't want to reverse by accident. : 3) Introduce := and deprecate = : : : Ok, nobody told = would be deprecated, but I've actually read that := would : do everything = does, so that = could be forgotten. Now, why not extend =, : instead of adding this Pascal-ism to Perl? That's still a possiblility. : I agree that Perl should get ideas from the maximum of languages, : including, of course, Java, VB, Pascal. I just don't see why introduce : syntatical elements of those languages, since the ideas could be done with : Plain Old Perl Syntax, that one inspired in the language for real : programmers, C, as it has always been through time. : : What I mean is, when I first say Ruby, I thought: That looks like a cool : language, it has most features of Perl, and supports some neat things Perl : doesn't... But when I saw it's Java-like syntax, I thought: Forget about : it! Perl syntax rules! What is it about . that seems to inspire allergic reactions in people? Surely it's not the . itself, but the requirement that you fit everything into that one syntactic mold. Perl's not going to do that. : The bottom line is: please don't change the syntax, unless it's : unavoidable. It will cost many time of reading code until finding bugs : because of operators that used to work and don't work anymore... That is a consideration, but there's no such thing as absolutes here. All change is avoidable at some price. I don't intend to pay that price. Larry
Re: s/./~/g
On Mon, Apr 23, 2001 at 01:16:57PM -0700, Larry Wall wrote: Branden writes: : I'm starting to be a bit worried with what I'm reading... : : 1) Use $obj.method instead of $obj-method : : : The big question is: why fix what is not broken? Why introduce Javaisms and : VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 : code (and Perl 5 programmers) for a zero net gain? It's not zero net gain, and I'm going to ignore the next person who says it. I agree it is not a zero net gain. But perhaps it needs to be spelled out for those who don't see the gain. Graham.
Re: s/./~/g
On 4/23/01 4:16 PM, Larry Wall wrote: What is it about . that seems to inspire allergic reactions in people? Surely it's not the . itself, but the requirement that you fit everything into that one syntactic mold. Perl's not going to do that. I don't mind it, but I always imagined: $obj-method(); $obj.attribute; or something vaguely C-ish like that. And I think most Perl folks like the - for class/object methods. It's a cute little arrow :) You'll have to make it very clear why . is a better fit for Perl 6 than - Otherwise people will probably mourn the missing Mr. Pointy ;) -John
Re: s/./~/g
Larry Wall wrote: Surely it's not the . itself, but the requirement that you fit everything into that one syntactic mold. Perl's not going to do that. I'm not opposed to the change, but I want to make one point: certain characters (like dot) are special in regexes, so when you want to search for them, you have to escape them, whether in vi, or with grep, or perl, or whatever. String concats with dot are uncommon enough; but member access is quite common. -- John Porter It's a sky-blue sky The satellites are out tonight let x = x
Re: s/./~/g
John Siracusa [EMAIL PROTECTED] writes: On 4/23/01 4:16 PM, Larry Wall wrote: What is it about . that seems to inspire allergic reactions in people? Surely it's not the . itself, but the requirement that you fit everything into that one syntactic mold. Perl's not going to do that. I don't mind it, but I always imagined: $obj-method(); $obj.attribute; Principle of uniform access says you really don't want to distinguish those two if you can possibly help it.. or something vaguely C-ish like that. And I think most Perl folks like the - for class/object methods. It's a cute little arrow :) You'll have to make it very clear why . is a better fit for Perl 6 than - Otherwise people will probably mourn the missing Mr. Pointy ;) -- Piers Cawley www.iterative-software.com
