John Porter wrote:
> We could y/$@%/@%$/ ...
... and create an alternate parser able to handle the full
internal internals API.
I have finally figured out the main motivation behind the
whole perl6 effort: the obfuscated perl contests were
getting repetitive.
Good night.
On Tue, 24 Apr 2001 18:39:09 -0700 (PDT), Larry Wall wrote:
>Edward Peschko writes:
>: I guess my question is what would be the syntax to access hashes? Would
>:
>: $hashref.{ }
>:
>: be that desirable? I really like ->{ } in that case..
>
>It won't be either of those. It'll simply be $hashre
On Tue, 24 Apr 2001 21:06:56 -0700 (PDT), Larry Wall wrote:
>: Ok, so what does:
>:
>: my %hash = ( 1 => 3);
>: my $hash = { 1 => 4};
>:
>: print $hash{1};
>:
>: print?
>
>4. You must say %hash{1} if you want the other.
Ok. So how about hash slices? Is $hash{$a, $b}, the faked
multidimension
On Tue, Apr 24, 2001 at 01:18:49PM +0100, Nick Ing-Simmons wrote:
> What _really_ want to do is a dynamically scoped peep-hole "optimize"
> (actually a rewrite) of the op tree - written in perl.
>
> But I can't do that
Yes, you can. Check out B::Generate.
--
Britain has football hooligans, Ger
Andy Dougherty <[EMAIL PROTECTED]> writes:
> Starting with 'P' is useful so we can keep our acronyms such as PMC and
> PDD :-). It's just an internal code name, so it probably doesn't matter if
> it's taken for another purpose.
PERIL (hi Tom!).
-- Johan
On Wed, Apr 25, 2001 at 11:53:33AM +0100, Dave Hartnoll wrote:
> What about using double-dot as the string concat operator:
>
> P5P6
> ->.
> . ..
> .=..= (or =.. for concat after)
You have missed a row for what the P5 .. operator becomes.
And the ... operator
[I am neutral as
What about using double-dot as the string concat operator:
P5P6
->.
. ..
.=..= (or =.. for concat after)
Many other operators already use doubled characters so this would not be an
oddity for perl and it would leave single dot for all the things Larry wants
it for without sacri
> On Wed, Apr 25, 2001 at 11:53:33AM +0100, Dave Hartnoll wrote:
> > What about using double-dot as the string concat operator:
> >
> > P5P6
> > ->.
> > . ..
> > .=..= (or =.. for concat after)
>
> You have missed a row for what the P5 .. operator becomes.
> And the ... operator
I wrote..
> ..(I would have suggested -> but that
> introduces problems with it meaning the same as comma in some situations.)
Ignore that. I'm getting confused with => sometimes meaning the same as
comma. I think I'll quit now before I dig myself any deeper :-)
Dave.
Lightning flashed, thunder crashed and "Brent Dax" <[EMAIL PROTECTED]> wh
ispered:
| $a.$b;
| a.$b;
|
| Unless we decide that objects can contain scalars
| and to access them you must prefix their name with $, the middle pair can't
| be object calls, so they're concat.
How about symbolic refs to
Lightning flashed, thunder crashed and Bart Lateur <[EMAIL PROTECTED]> whis
pered:
| I'm really beginning to like
|
| $string3 = $string1 _ $string2;
|
| The underscore indeed "connects" the two strings.
This still breaks because _ is a valid word character. Again, we have to
make the la
Suggestion: prepend a ~ or , to numeric comparison operators
Addresses the key concerns:
o frees up .
o spaces insensitive (though cmp, eq, ...do care about spaces)
o using the , instead of ~ would be 1 keystroke on most keyboards
o ~ and , visually intuit a string (~ more than ,)
o avoids:
At 04:12 PM 25/04/2001 +0200, Bart Lateur wrote:
>On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote:
> >If the idea is supporting arbitrary add-on operators...
>
>I think I second that. I would think of a fixed table for the built-in
>ones, and a linked list for the add-ons. It's not necessary tha
At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Resizing the vtable at runtime is a really dodgy thing. There are some
>: rather huge threading implications here--changing their size (as opposed to
>: using up a limited number of "uncommitted" spots we leave at the end) mea
On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote:
>If the idea is supporting arbitrary add-on operators, which I believe will
>be done seldom, for only some specific classes, wouldn't it be better to
>have a ``catch all'' entry for operators different than the built-in ones?
>
>Of course, add-
At 09:39 AM 25/04/2001 -0400, Dan Sugalski wrote:
>At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>>I think we definitely have to be able to resize vtables at compile time,
>>which is a form of run time. It's vaguely possible we could restrict
>>multithreading during compile phase.
>
>We need to
At 06:37 PM 4/24/2001 -0500, David L. Nicol wrote:
>Uri Guttman wrote:
>
> > i was looking at dan's PMC arena allocator struct and it reminded me of
> > something an older language can do (which MJD has likened to an early
> > perl :). ever heard of AREA in PL/I? it was a large chunk of ram
> > de
Larry Wall wrote:
>
>Branden writes:
>: 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
From: [EMAIL PROTECTED] (Randal L. Schwartz)
Date: 25 Apr 2001 07:23:44 -0700
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Lines: 50
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
> "Peter" == Peter Scott <[EMA
Uri Guttman wrote:
> .= could still be left working as that is a complete separate op from
> method invocation.
I see a major potential problem with that.
Assuming (which I do) that the equals operator will be
overridable, then you'll need to be able to write
$obj.='x';
meaning this (
On Wed, 25 Apr 2001 08:25:40 -0400, Stephen P. Potter wrote:
>| I'm really beginning to like
>|
>| $string3 = $string1 _ $string2;
>|
>| The underscore indeed "connects" the two strings.
>
>This still breaks because _ is a valid word character.
So are "cmp", "and", "lt", and the proposed
Bart Lateur writes:
: Ok. So how about hash slices? Is $hash{$a, $b}, the faked
: multidimensional hash, going to go?
Yes, fake multidimensional hashes will be defenestrated.
Larry
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 al
At 01:36 PM 4/25/2001 -0400, Eric Roode wrote:
>John Porter wrote:
> >
> >Dan Sugalski wrote:
> >> The one downside is that you'd have essentially your own private
> language.
> >> Whether this is a bad thing or not is a separate issue, of course.
> >
> >IIUC, this ability is precisely what Larry
John Porter wrote:
>
>Dan Sugalski wrote:
>> The one downside is that you'd have essentially your own private language.
>> Whether this is a bad thing or not is a separate issue, of course.
>
>IIUC, this ability is precisely what Larry was saying Perl6 would have.
I may have my history wrong her
From: "Larry Wall" <[EMAIL PROTECTED]>
Sent: Monday, April 23, 2001 1:10 PM
Subject: Re: Tying & Overloading
> Helgason writes:
> : I _really_ think dot-syntax would make perl prettier as well as make it
> : more acceptable to the world of javacsharpbasic droids. Which is some
> : kind of goal, no
On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote:
[snip four examples are obvious ...]
>>> $a."b";
If a has a method 'foo' such that
$a.foo
is the standard invocation, it would be nice when $b = 'foo' for
$a.foo === $a."$b" === $a.$b
How I see the . operato
Nathan Wiger wrote:
>
>Here's something I was thinking about at lunch:
>
> $concated_number = "$number" + "$other_number";
> $numerical_add = $number + $other_number;
>
One major, MAJOR pet peeve I have wrt Javascript is that it uses
+ to mean concatenation as well as addition, and that it
On Wed, Apr 25, 2001 at 12:44:11PM -0400, James Mastros wrote:
> I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY
> PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS?
You've made it impossible for anyone to answer you until you tell us
what "good" means to
At 11:28 AM 25/04/2001 -0400, Uri Guttman wrote:
>well, the real goal is persistancy, so how about this idea?
>
>instead of using Data::Dumper and cousins to stringify a structure,
>write it out and parse it back in, we provide a module which copies and
>converts a structure to an area and convert
At 11:34 AM 25/04/2001 -0400, Dan Sugalski wrote:
>At 11:01 AM 4/25/2001 -0300, Branden 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
> You're thinking of objects as references and references as akin to
> pointers, which makes sense because that's how they're implemented in Perl
> 5. If you think of objects as their own entities, however, or think of
> references as something other than pointers (in particular, something that
>
On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote:
> IMHO, . can DWIM in most cases even if it's both object deref _and_
> concat--without paying any attention to whitespace.
Please, no. Some of us have to *teach* this language.
--
The trouble with computers is that they do what you tel
On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote:
> > Doesn't ~ look like a piece of string to you? :-)
> It looks like a bitwise op to me, personally.
That's because every time you've used it in Perl, it's been a bitwise
op. Sapir-Whorf, and all that.
--
So what if I have a fertil
Suggestion: prepend a ~ or , to numeric comparison operators
Addresses the key concerns:
o frees up .
o spaces insensitive (though cmp, eq, ...do care about spaces)
o using the , instead of ~ would be 1 keystroke on most keyboards
o ~ and , visually intuit a string (~ more than ,)
o avoids:
On Wed, Apr 25, 2001 at 06:46:20PM +0100, Simon Cozens wrote:
> On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote:
> > > Doesn't ~ look like a piece of string to you? :-)
> > It looks like a bitwise op to me, personally.
>
> That's because every time you've used it in Perl, it's been
> '.' is already, to some extent, space sensitive anyway, because it has
> to pull double duty as a decimal point, as well.
>
> '4.5' (4.5) vs '4 .5' (45) vs '4. 5' (missing operator)
beautiful. Then extending this is simple, consistent, easy to read, compatible
with perl5..
Ed
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 ->
>
At 03:08 PM 4/25/2001 -0300, Branden wrote:
>At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
>>Seriously, I don't see why this should be a scary thing. So, the opcode
>>table's extendable. So what? It'll make language X mode simpler, for some
>>value of X, if that language can load in its own
At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
>Seriously, I don't see why this should be a scary thing. So, the opcode
>table's extendable. So what? It'll make language X mode simpler, for some
>value of X, if that language can load in its own set of extended opcodes.
>Perhaps someone'll w
At 02:01 PM 4/25/2001 -0300, Branden wrote:
>At 11:34 AM 25/04/2001 -0400, Dan Sugalski wrote:
>>At 11:01 AM 4/25/2001 -0300, Branden 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 ope
At 11:01 AM 4/25/2001 -0300, Branden wrote:
>At 09:39 AM 25/04/2001 -0400, Dan Sugalski wrote:
>>At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>>>I think we definitely have to be able to resize vtables at compile time,
>>>which is a form of run time. It's vaguely possible we could restrict
>>>mu
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 06:37 PM 4/24/2001 -0500, David L. Nicol wrote:
>> Uri Guttman wrote:
>>
>> > i was looking at dan's PMC arena allocator struct and it reminded me of
>> > something an older language can do (which MJD has likened to an early
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, an
On Wednesday 25 April 2001 21:37, Edward Peschko wrote:
> > '.' is already, to some extent, space sensitive anyway, because it
> > has to pull double duty as a decimal point, as well.
> >
> > '4.5' (4.5) vs '4 .5' (45) vs '4. 5' (missing operator)
>
> beautiful. Then extending this is simple, cons
Edward Peschko writes:
> I think its really time to have a vote on this, I think that all
> that has been said about this issue has been said...
It's definitely not time for a vote. Larry'll take what's been said
by both sides and make a decision, just one of a zillion different
decisions that h
> > beautiful. Then extending this is simple, consistent, easy to read,
> > compatible with perl5..
>
> I'm not sure that that was the point I was trying to make.
> If nothing else, the '.' would then be responsible for *three*
> different actions.
Right, but what *I* am saying is that any give
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:
: > On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote:
: > > > Please, no. Some of us have to *teach* this language.
: > > Then I guess that either space sen
>
> More often that you might think. I see Perl folks who love white
> space writing:
>
> print
> $cgi -> header,
> $cgi -> start_html,
> $cgi -> h2( 'my page' ),
> $cgi -> hr,
> $cgi -> a(
> { -href => 'http://geeknest.com' },
>
On Wed, Apr 25, 2001 at 06:19:40PM +, Fred Heutte wrote:
> Yes, I know ~ is the bitwise negation operator. Have you EVER used it?
Today, in fact:
fcntl($fh, F_SETFL, $flags & ~O_NONBLOCK) or die "fcntl: $!";
- Damien
I'm just gonna post this, then back off and listen (been yapping too
much...)
The previous discussions about string concat and how to replace . have
revealed that people are somewhat divided over whether replacing -> with
. is actually good thing or not.
I'm just curious what the arguments for a
On Wed, 25 Apr 2001, James Mastros wrote:
> I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY
> PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS?
It might be prudent to avoid rushing to judgment until the bigger picture
becomes clearer. We have yet to see
Nathan Wiger <[EMAIL PROTECTED]> writes:
>- C compatibility. One of Perl's great strengths
> over other HLL's is C compatibility. Though
> this is still arguably not as good as it can be,
> why distance ourselves from the language we're
> trying to interact with?
You're
On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote:
> > Please, no. Some of us have to *teach* this language.
> Then I guess that either space sensitive '.' is the answer
Sorry. I'll try it again.
SPACE SENSITIVE and SOME OF US HAVE TO TEACH IT. Do you understand yet?
Are you *reall
On Thu, Apr 26, 2001 at 03:16:46AM +0100, Simon Cozens wrote:
> On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote:
> > > Please, no. Some of us have to *teach* this language.
> > Then I guess that either space sensitive '.' is the answer
>
> Sorry. I'll try it again.
>
> SPACE SENSI
On Thu, Apr 26, 2001 at 01:03:50AM +0200, Paul Johnson wrote:
> On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote:
>
> > I think its really time to have a vote on this
>
> Aaargh. I don't. Wouldn't you rather wait and see what Larry is
> planning with all this? I doubt the propos
On Wednesday 25 April 2001 18:33, Edward Peschko wrote:
> On Wed, Apr 25, 2001 at 06:30:37PM +0100, Simon Cozens wrote:
> > On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote:
> > > IMHO, . can DWIM in most cases even if it's both object deref
> > > _and_ concat--without paying any attentio
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 " . $mores
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 ->
:
On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote:
> I think its really time to have a vote on this
Aaargh. I don't. Wouldn't you rather wait and see what Larry is
planning with all this? I doubt the proposed changes are gratuitous,
and I think he's got a pretty good track record
Edward Peschko <[EMAIL PROTECTED]> writes:
> > > beautiful. Then extending this is simple, consistent, easy to read,
> > > compatible with perl5..
> >
> > I'm not sure that that was the point I was trying to make.
> > If nothing else, the '.' would then be responsible for *three*
> > different
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 onl
On Wed, Apr 25, 2001 at 06:30:37PM +0100, Simon Cozens wrote:
> On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote:
> > IMHO, . can DWIM in most cases even if it's both object deref _and_
> > concat--without paying any attention to whitespace.
>
> Please, no. Some of us have to *teach* thi
On 4/25/01 5:52 PM, 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.
Then remove it from the reference syntax! :)
64 matches
Mail list logo
