Re: Curious: -> vs .
On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:
>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:
label1!caption = "Hi!"
is the same as
label1.caption = "Hi!"
So why not
$object!method("foo", "bar");
--
Bart.
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
On Thu, 26 Apr 2001 10:15:14 +0200, Bart Lateur wrote: >For example, in > > -3.4 > >and in > > 2-3.4 > >the - sign is a *different* kind of operator. No conflict. Well alright, in the first line, the "-" might be part of the number. Replace "3.4" with a variable and it does hold: -$x $y-$x Different kinds of operators. -- Bart.
Re: how about just juxtaposing? (Re: Sane "+" string concat proposal)
On Wed, Apr 25, 2001 at 12:36:33AM -0500, David L. Nicol wrote:
>
> Ah.. I knew I'd find the thread in here somewhere.
>
> The problems go away if you allow white space to signify.
>
>
> > [...] Consider
> >
> > print "Foo"
> > foo("bar");
> >
> > Did the author forget a semi-colon, or did they intend to concatinate
> > there? Also, consider this...
> they forgot a semicolon. A spaceless juxtaposed concat would look like
>
> print "Foo"foo("bar");
Ick, please no. One of the things I like about Perl, as opposed to
Java say, is that a newline is almost never considered a statement
terminator. In Java (and probably a bunch of other languages), to
write a long string you need to do the equivalent of...
$foo = 'some stuff \
some more stuff \
and more stuff';
That or a bunch of concatinations. In Perl we don't have this problem
(we also have here-docs YAY!) This is very common in any code that
involves alot of embedded text (such as SQL or HTML).
The solution to the lack of a semi-colon dangerously stretches this
nice feature of Perl.
It also looks like a smashed jumble. The eye trips on all those
quotes without any distinguishing whitespace or word breaks.
print "Foo"foo('bar');
could easily be confused at first glance with
print "Foo foo('bar')";
the eye has alot of trouble distinguishing the two.
I think Nat said it best in his "What's Up With Those Python Fucks
Anyway" talk. Whitespace (or lack thereof) as syntax misses the key
point about whitespace in code. Its used to disambiguate and clarify.
Hijacking it as syntax means it can no longer be used as such.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Ooops, fatal mutation in the test script.
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'$four"five"$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
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: 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: Curious: -> vs .
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")];
(If we really wanted to steal from Objective C, we'd use:
[$object method:"foo":"bar"]
but it seems Larry has claimed the colon.)
>
> --
> Bart.
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: 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: deferred vtable assignment?
At 03:02 PM 4/26/2001 -0500, David L. Nicol wrote: >Dan Sugalski wrote: > > > >What if the decision in-vtable or not-in-vtable is deferred? > > > > That's doable, I think, though I can see some issues. > > >how about a two-tiered vtable, where a single high bit, if set, >indicates extended handling, or at least consultation of >a different table. > >I guess that amounts to the same as having a set number of >"extended" entries that indicate check elsewhere to decide >what do do now. Yeah, I think this might be what we do, but there are still issues. I'd rather know at runtime (or, rather, after BEGIN time) what I've got handy for vtable entries, since it's at that point that the vtable messiness will be finalized as the bytecode hits the optimizer. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
PDD for debugger
=head1 The Perl6 Debugger
=head2 Perl-level Debugging
=head3 Existing Functionality
The following is a list of the functionality in the existing Perl5
debugger; this functionality should, of course, be maintained for
backwards compatibility.
=over 4
=item T
Stack trace.
=item s [expr]
Single step [in expr].
=item n [expr]
Next, steps over subroutine calls [in expr].
=item
Repeat last n or s command.
=item r
Return from current subroutine.
=item c [line|sub]
Continue; optionally inserts a one-time-only breakpoint at the
specified position.
=item l min+incr
List incr+1 lines starting at min.
=item l min-max
List lines min through max.
=item l line
List single line.
=item l subname
List first window of lines from subroutine.
=item l C<$var>
List first window of lines from subroutine referenced by C<$var>.
=item l
List next window of lines.
=item -
List previous window of lines.
=item w [line]
List window around line.
=item .
Return to the executed line.
=item f filename
Switch to viewing filename. File must be already loaded. Filename may
be either the full name of the file, or a regular expression matching
the full file name: f /home/me/foo.pl and f oo\. may access the same
file. Evals (with saved bodies) are considered to be filenames: f
(eval 7) and f eval 7\b access the body of the 7th eval (in the order
of execution).
=item /pattern/
Search forwards for pattern; final / is optional.
=item ?pattern?
Search backwards for pattern; final ? is optional.
=item L
List all breakpoints and actions.
=item S [[!]pattern]
List subroutine names [not] matching pattern.
=item t
Toggle trace mode.
=item t expr
Trace through execution of expr.
=item b [line] [condition]
Set breakpoint; line defaults to the current execution line; condition
breaks if it evaluates to true, defaults to '1'.
=item b subname [condition]
Set breakpoint at first line of subroutine.
=item b C<$var>
Set breakpoint at first line of subroutine referenced by C<$var>.
=item b load filename
Set breakpoint on `require'ing the given file.
=item b postpone subname [condition]
Set breakpoint at first line of subroutine after it is compiled.
=item b compile subname
Stop after the subroutine is compiled.
=item d [line]
Delete the breakpoint for line.
=item D
Delete all breakpoints.
=item a [line] command
Set an action to be done before the line is executed; line defaults to
the current execution line. Sequence is: check for
breakpoint/watchpoint, print line if necessary, do action, prompt user
if necessary, execute line.
=item a [line]
Delete the action for line.
=item A
Delete all actions.
=item W expr
Add a global watch-expression.
=item W
Delete all watch-expressions.
=item V [pkg [vars]]
List some (default all) variables in package (default current). Use
~pattern and !pattern for positive and negative regexps.
=item X [vars]
Same as "V currentpackage [vars]".
=item x expr
Evals expression in array context, dumps the result.
=item m expr
Evals expression in array context, prints methods callable on the
first element of the result.
=item m class
Prints methods callable via the given class.
=item < ?
List Perl commands to run before each prompt.
=item < expr
Define Perl command to run before each prompt.
=item << expr
Add to the list of Perl commands to run before each prompt.
=item > ?
List Perl commands to run after each prompt.
=item > expr
Define Perl command to run after each prompt.
=item >> expr
Add to the list of Perl commands to run after each prompt.
=item { db_command
Define debugger command to run before each prompt.
=item { ?
List debugger commands to run before each prompt.
=item < expr
Define Perl command to run before each prompt.
=item {{ db_command
Add to the list of debugger commands to run before each prompt.
=item ! number
Redo a previous command (default previous command).
=item ! -number
Redo number'th-to-last command.
=item ! pattern
Redo last command that started with pattern. See 'O recallCommand' too.
=item !! cmd
Run cmd in a subprocess (reads from DB::IN, writes to DB::OUT) See 'O
shellBang' too.
=item H -number
Display last number commands (default all).
=item p expr
Same as "print {DB::OUT} expr" in current package.
=item |dbcmd
Run debugger command, piping DB::OUT to current pager.
=item ||dbcmd
Same as |dbcmd but DB::OUT is temporarilly select()ed as well.
=item = [alias value]
Define a command alias, or list c
Re: PDD for debugger
You list the particular commands as 'existing functionality'. I think this is a mistake, even if you didn't mean it that way, if it was just an artifact of your presentation format. I know that breaking debugging habits that have been ingrained in at the spinal level may be hard to break, but thinking that "we must save t" (or any particular command) is in my opinion the wrong to approach a new design. Rather, look at the higher level concepts; take a look, nay, several looks, at other command line debuggers, what commands do they offer? Collect and group the concepts. Take a look at graphical debuggers (boo! hiss! I hear the chorus moaning) -- but seriously: take a look at, say, ddd and its data displays. What kind of hooks, APIs, design, we can supply so that making the life of "gooey looser interfaces" is easier? Take a look at various Perl debugging books and tutorials: what (lack of) features they apologize about? Take a look at perltrap and similar documents, like beginners' tips and ticks: what are the common mistakes? Also, one current problem with the debugger should of course harass us no more in Perl 6: the lexical scope of the debugger is different from the scope of the debuggee. (You may have mentioned this but I didn't see it.) The debugger must be able to see two scopes at the same time: its own and the debuggee's. Finally my personal pet peeve that I wish would be banished: 'h' should give just a short summary, not the full story that needs a pager. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: deferred vtable assignment?
Dan Sugalski wrote: > >What if the decision in-vtable or not-in-vtable is deferred? > > That's doable, I think, though I can see some issues. how about a two-tiered vtable, where a single high bit, if set, indicates extended handling, or at least consultation of a different table. I guess that amounts to the same as having a set number of "extended" entries that indicate check elsewhere to decide what do do now. Which again causes mind-expoloding possibilities, except that there is no reason to keep all possibilities in mind, just open up the pandorabox and let all the evil out. > teddy bears get drunk and they all say "yodelahihu"
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: 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: 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: 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: 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: 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 K&R 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: Curious: -> vs .
Buddha Buck <[EMAIL PROTECTED]> writes:
> 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.
Oops, meant anonymous array.
> 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.
Hmm... I plead posting late at night.
> 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
Apart from the fact that we're adding one more meaning to [], one
which has no mnemonic relationship with arrays, no reason at all.
--
Piers Cawley
www.iterative-software.com
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: 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
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: deferred vtable assignment?
At 05:14 PM 4/25/2001 -0500, David L. Nicol wrote: >Dan Sugalski wrote: > > > >2) Anyway, even resizing vtables we would need some more indirection to > > >determine in which position of the vtable is which operator. > > > > No. Each operator goes in a fixed position in the vtable, and it's the same > > for each table. Anything else is nasty, error prone, and slow. > >What if the decision in-vtable or not-in-vtable is deferred? The size >of the vtable could be chosen late in the compilation. There could be >hints. That's doable, I think, though I can see some issues. It means that the bytecode compiler will need to do some reorganization and possibly emit different opcode streams. That's not a huge issue, but it does mean that we'll need to do extra processing of bytecode-compiled modules. (Especially ones loaded at runtime, unless we restrict the module compilation sequence to not use extra vtable entries, or spit out two streams of bytecode and choose which to use based on the number of remaining vtable entries) The logic could get potentially rather dodgy when twiddling code sequences from one way to the other. I'd really just as soon not deal with the issue this way, though that doesn't mean it won't be the way we end up going. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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
