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: 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: 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
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.
