Re: C or SH like string cat proposal
On Wed, Apr 25, 2001 at 12:10:10AM -0500, David L. Nicol wrote: That means, if you have a long list of scalars rou want to cat together and it will run over the edge of your line you can do this: $onethroughten = $one$two$three$four$five $six$seven$eight$nine$ten; I think the proper phrase here is ick. To my non-C, non-Shell programming eyes, that's just a confused jumble. It'll also play hell with trying to mix strings in there. I could live my entire life without seeing: $foo = $one$two'three'$fourfive$six Will someone please explain to me the indirect object syntax which this allegedly steps on? (The hellish abomination of ;) indirect object syntax works like this: $obj = new Some::Module @args; to mean $obj = Some::Module-new(@args); Any proposal which tries to use whitespace as a concatination operator runs into its territory, but I don't think yours would cause problems (except for the rash of patients admitted to local hospitals with bleeding eyes). -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Let me check my notes...
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: Dot can DWIM without whitespace
On Wed, Apr 25, 2001 at 08:33:33AM -0400, Stephen P. Potter wrote: How about symbolic refs to function names? $a = $x ? hop : skip; $b = $y ? scotch : soda; $a.$b;# call one of hop.scotch, skip.scotch, hop.soda, skip.soda 5.005_03 and under required parens after the method reference $obj-$meth_name(); 5.6.0 appears to have removed that requirement, but I don't see why that couldn't be required again in Perl 6 to disambiguate if needed. | Alternately, we can overload . to do a deref on (blessed?) references, and | concat otherwise. I think this would lead to hard to find bugs when someone mispelled something. I think it would also throw Dan into convusive fits. Additionally, it would make finding method calls lexically near impossible. I'd like to keep Perl 6 refactorable as much as possible. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One BOFH excuse #356: the daemons! the daemons! the terrible daemons!
Re: Dot can DWIM without whitespace
On Wed, Apr 25, 2001 at 07:23:47PM -0700, Edward Peschko wrote: On Thu, Apr 26, 2001 at 03:16:46AM +0100, Simon Cozens wrote: SPACE SENSITIVE and SOME OF US HAVE TO TEACH IT. Do you understand yet? Just for the record, I'm totally with Simon here. Having . do triple duty (decimals, method calls and string concat) will be hard enough to teach. Throw obscure whitespace rules in there and you'll spend all day trying to explain it. The problem already comes up... '4. 5' is not the same as '4.5'. '.' is *already* doing double duty as decimal mark. The fact that you don't see this very often shows exactly how rare the mistake arises. Most people, by around first grade, understand that 4.5 is a number. 4. 5 is (thank goodness) a syntax error, so any confusion is resolved immediately. '4 .5' for some reason is not, but as Casey pointed out that's probably a parsing hiccup. Additionally, its pretty damn rare for anyone to want to concatenate two bare numbers. I think the 'tutorial' will come from experience. When the error that you get from $a.$b comes up (and it should be a syntax error) you'll see exactly what is wrong. If $a. $b, again, syntax error. Only $a . $b should be allowed. The only point of contention would be if someone said $a . b, when they meant $a.b. And how often will that occur? Very often, because I'd expect $a.$b to work and be very surprised when it fails! Very little else in Perl is white-space sensitive without very good, fairly obvious reasons (as with decimal numbers above), let's avoid it here. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One They just don't make any good porn music anymore, do they? - WXDX DJ refering to More, More, More
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: Strings vs Numbers (Re: Tying Overloading)
On Wed, 25 Apr 2001 06:09:56 -0700 (PDT), Larry Wall wrote:
Bart Lateur writes:
: Er... hip hip hurray?!?!
:
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs.
: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?
$foo{THERE} always means the hashref in $foo. %foo{THERE} always means
the hashref in %foo. %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref. foo by itself in
a scalar context means a coderef. It's gonna be pretty consistent.
Yeah. But no cheers then. The problem still remains: you can access a
hash in the normal way in plain code, but inside a sub, you can mainly
only access a passed hash through a reference.
It's annoying to basically having two ways of doing something, and one
of them can't be used half of the time.
Even though @foo and %foo may be two different structures, a scalar $foo
can only reference one of them at a time.
Are you going to provide a simpler aliasing mechanism to turn a hash
reference, for example as passed to a sub as an argument, back into the
full-blown hash? Simpler (and safer) than the much frowned upon
assignment to a tyeglob, that is.
--
Bart.
Re: Dot can DWIM without whitespace
At 09:16 AM 4/26/2001 +0100, Michael G Schwern wrote:
On Wed, Apr 25, 2001 at 08:33:33AM -0400, Stephen P. Potter wrote:
| Alternately, we can overload . to do a deref on (blessed?) references,
| and
| concat otherwise.
I think this would lead to hard to find bugs when someone mispelled
something.
I think it would also throw Dan into convusive fits.
Nah. Not convulsive ones, at least. (I'll work from the example Jon Orwant
set instead... :)
Additionally, it
would make finding method calls lexically near impossible. I'd like
to keep Perl 6 refactorable as much as possible.
While it doesn't argue for or against the current period issue, figuring
out what code really does is more the provence of the parser rather than
analysis code. ('Specially since a single use could potentially throw
things subtly out of whack)
Which means we really ought to have hooks into the parser, or a tool to
analyze the unoptimized bytecode from the parser, to do this sort of thing.
B::Deparse for perl 6, say.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Curious: - vs .
the idea of a dereference operator dumbfounds lots
of folks. What's an object got to do with a reference, much less a
pointer? A p5 object is very confusing to others for this reason, and so
is the syntax.
So you want a method invocation syntax that doesn't remind people of
references. OK. But why does it have to be the dot? It is already taken.
Sorry. Use an operator that doesn't exist yet in Perl. For example, old
style VB used ! to connect objects and their properties:
$object!method(foo, bar);
It doesn't have to be the dot. But the plain fact is that the dot is
generally recognized in this way; why is making Perl syntax more
recognized a bad thing? If what we're after is making Perl better, then
one of the primary improvements should be making objects more readable for
the multi-language programmer. I'm really not against '-', but then
again, I *like* that
an-object-is-a-reference-which-means-I-can-poke-and-prod-it-and-embed-it-etc.
Even so, I recognize that it doesn't make Perl more readable, especially
when glob syntax is used to manipulate the reference table.
A traditionally negating symbol ('!') is the last character I would want
to see. As for VB ;)
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: Flexible parsing (was Tying Overloading)
Eric Roode writes: : John Porter wrote: : IIUC, this ability is precisely what Larry was saying Perl6 would have. : : I may have my history wrong here, but didn't Ada try that? Not at all. The syntax of Ada was nailed down tighter that almost any language that ever existed. : Super-flexible, redefinable syntax? And wasn't the result that nobody could : read anybody else's code, so Standards Committees were set up to : define Legal Styles that basically reduced the syntaxes that you could : use to just the One Standard Style? Gee, you must be thinking of KR C. :-) In any event, I'm not worried about it, as long as people predeclare exactly which variant they're using. And I'm also not worried that we'll have any lack of style police trying to enforce Standard Perl 6. Larry
Re: Flexible parsing (was Tying Overloading)
Dan Sugalski writes: : And on the other hand you have things like Forth where every program : essentially defines its own variant of the language, and that works out : reasonably well. (Granted it's more of a niche language, especially today, : but that's probably more due to its RPN syntax) Perhaps. I would also attribute Forth's lack of success in part to its lack of standardization, but only in conjunction with its lack of standardization, if you take my meaning. The core distribution was too small to establish a common culture. Despite the fact that we're trying to pare down the actual core core of Perl, I don't think the standard distribution is going to fall into the error of providing too little guidance on cultural matters, if for no other reason than we must minimally provide for translated Perl 5 programs. I would also argue that Forth's diversity was driven in part by its lack of support for other programming paradigms. I don't see Perl falling into that trap any time soon either... Larry
Re: Flexible parsing (was Tying Overloading)
On Thu, Apr 26, 2001 at 04:13:30PM -0700, Larry Wall wrote: Eric Roode writes: : John Porter wrote: : IIUC, this ability is precisely what Larry was saying Perl6 would have. : : I may have my history wrong here, but didn't Ada try that? Not at all. The syntax of Ada was nailed down tighter that almost any language that ever existed. In a sick way I kinda liked how compilers were able to give out error messages not unlike: foo.ada: line 231: Violation of sections 7.8.3, 9.11.5b and 10.0.16: see the LRM. (LRM being the Language Reference Manual.) Truly coding by the book. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
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: YAYAYA string concat proposal
I have a different suggestion: replace - with ~ ~ is already Perlish for glues to something related. That's a different construct than concatenates. Fred
Re: Curious: - vs .
Buddha Buck [EMAIL PROTECTED] writes: Bart Lateur [EMAIL PROTECTED] writes: On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: So why not $object!method(foo, bar); In my opinion, because it doesn't provide sufficient visual distinction between $object and method(). At a glance, especially on a crowded page, it's similar in appearance to $objectImethod, for instance. $object.method() has a visual separator (although I'd prefer $object-method()). How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. -- Piers Cawley www.iterative-software.com
Re: Flexible parsing (was Tying Overloading)
On Thu, Apr 26, 2001 at 06:25:03PM -0500, Jarkko Hietaniemi wrote: In a sick way I kinda liked how compilers were able to give out error messages not unlike: foo.ada: line 231: Violation of sections 7.8.3, 9.11.5b and 10.0.16: see the LRM. Ever used the Mac C compiler? -- Language shapes the way we think, and determines what we can think about. -- B. L. Whorf
Re: Curious: - vs .
Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: Bart Lateur [EMAIL PROTECTED] writes: On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: So why not $object!method(foo, bar); In my opinion, because it doesn't provide sufficient visual distinction between $object and method(). At a glance, especially on a crowded page, it's similar in appearance to $objectImethod, for instance. $object.method() has a visual separator (although I'd prefer $object-method()). How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. I thought ($one, $two, $three) was an anonymous list. Seriously, I hadn't considered that their may be a problem with the syntax I gave. How would you, under Perl5, interpret the expression I used. To me, it looks like a syntax error. '$object method(foo,bar)' isn't a valid method call, so it can't be a ref to an anonymous list of one value. Other than severe dependence on the comma, is there any reason why we couldn't have the following? $foo = [$one]; # array ref $baz = [$obj,funcall() ]; # array ref $quux = [$one,$two,$three]; # array ref $bar = [$obj method() ]; # method call $bat = [$one $two $three]; # syntax error -- Piers Cawley www.iterative-software.com
string concatenation operator - please stop.
To me this whole thing looks like bike shedding at it's worst at this point. Please stop and read this http://www.freebsd.org/doc/en_US.ISO_8859-1/books/faq/misc.html#BIKESHED-PAINTING and possibly this http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers before writing more on the subject, huh? - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
RE: Curious: - vs .
$foo = [$one, $two, $three]; # creates an anonymous list. $foo = [$object method(foo, bar)]; This would interpret as $foo[0] == $object, etc... Ilya -Original Message- From: Buddha Buck [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 11:20 PM To: Piers Cawley Cc: Bart Lateur; [EMAIL PROTECTED] Subject: Re: Curious: - vs . Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: Bart Lateur [EMAIL PROTECTED] writes: On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: So why not $object!method(foo, bar); In my opinion, because it doesn't provide sufficient visual distinction between $object and method(). At a glance, especially on a crowded page, it's similar in appearance to $objectImethod, for instance. $object.method() has a visual separator (although I'd prefer $object-method()). How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. I thought ($one, $two, $three) was an anonymous list. Seriously, I hadn't considered that their may be a problem with the syntax I gave. How would you, under Perl5, interpret the expression I used. To me, it looks like a syntax error. '$object method(foo,bar)' isn't a valid method call, so it can't be a ref to an anonymous list of one value. Other than severe dependence on the comma, is there any reason why we couldn't have the following? $foo = [$one]; # array ref $baz = [$obj,funcall() ]; # array ref $quux = [$one,$two,$three]; # array ref $bar = [$obj method() ]; # method call $bat = [$one $two $three]; # syntax error -- Piers Cawley www.iterative-software.com
Re: Flexible parsing (was Tying Overloading)
On Fri, Apr 27, 2001 at 02:28:58AM +0100, Simon Cozens wrote: On Thu, Apr 26, 2001 at 06:25:03PM -0500, Jarkko Hietaniemi wrote: In a sick way I kinda liked how compilers were able to give out error messages not unlike: foo.ada: line 231: Violation of sections 7.8.3, 9.11.5b and 10.0.16: see the LRM. Ever used the Mac C compiler? Yes...? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
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: Strings vs Numbers (Re: Tying Overloading)
Bart Lateur writes: : Yeah. But no cheers then. The problem still remains: you can access a : hash in the normal way in plain code, but inside a sub, you can mainly : only access a passed hash through a reference. Won't be a problem. : It's annoying to basically having two ways of doing something, and one : of them can't be used half of the time. : : Even though @foo and %foo may be two different structures, a scalar $foo : can only reference one of them at a time. : : Are you going to provide a simpler aliasing mechanism to turn a hash : reference, for example as passed to a sub as an argument, back into the : full-blown hash? Simpler (and safer) than the much frowned upon : assignment to a tyeglob, that is. Yes. In fact, a %hash prototype will provide a scalar context, forcing a %foo arg to return a reference, and that ref will be aliased to %hash. You will be required to do something explicit to declare an argument that supplies list context and slurps the rest of the args. (There will also be an explicit way to slurp a list of items but supply scalar context.) Larry
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
