On Wed, May 09, 2001 at 02:05:48PM -0700, Austin Hastings wrote:
> Will it be possible to define "pointer classes", a la C++, in a
> relatively "smooth" manner?
>
> That is, an object R has methods of its own as well as methods
> belonging to the "referred to" object?
Sounds you're looking for a
Will it be possible to define "pointer classes", a la C++, in a
relatively "smooth" manner?
That is, an object R has methods of its own as well as methods
belonging to the "referred to" object?
E_G: print "$R.toString is a reference to $R->toString";
Or some such? The notion of $R.getData.toStr
James Mastros <[EMAIL PROTECTED]> writes:
>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
Bart Lateur <[EMAIL PROTECTED]> writes:
>On 24 Apr 2001 00:29:23 -0700, Russ Allbery wrote:
>
>>How do you concatenate together a list of variables that's longer than one
>>line without using super-long lines? Going to the shell syntax of:
>>
>>PATH=/some/long:/bunch/of:/stuff
>>PATH="${P
At 05:41 PM 4/30/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: 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 lan
At 11:05 PM 4/30/2001 +0200, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Dan Sugalski) wrote on 25.04.01 in
><[EMAIL PROTECTED]>:
>
> > If you have the double-indirect, the window of vulnerability is smaller,
> > but it's still there if you're running multithreaded.
>
>Looks zero-sized to me. One
[EMAIL PROTECTED] (Dan Sugalski) wrote on 25.04.01 in
<[EMAIL PROTECTED]>:
> If you have the double-indirect, the window of vulnerability is smaller,
> but it's still there if you're running multithreaded.
Looks zero-sized to me. One memory write, let the garbage collector
collect the old vt
Dan Sugalski writes:
: 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
On Sat, Apr 28, 2001 at 03:44:25PM -0700, Larry Wall wrote:
> Dan Sugalski writes:
> : I hadn't really considered having a separate module for each type of site
> : policy decision.
>
> Er, neither had I. Each site only has one policy file. I just want it
> named after the actual site, not som
Bart Lateur wrote:
> 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.
>
> ...
>
> Are you going to provide a simpler aliasing mechanism to turn a hash
>
> If I work at OReilly, I don't need a Local:: in front of my
> OReilly to tell me that it's a local namespace.
but you need "OReilly" in front? do you label your clothes "Shirt" and
"Pants" as well? might be orthagonal but the top level should serve
a useful purpose instead of something along th
Damian Conway wrote:
> If it's a policy, it should go under Policy::
If it's an OReilly site module, it should go under OReilly, eh?
What's general and what's specific is entirely a matter of
perspective, since "OReilly" and "Policy" are entirely
orthogonal concepts.
> Surely you wouldn't condo
On Sun, Apr 29, 2001 at 05:06:03PM -0400, John Porter wrote:
> OReilly::Policy is (or might be) still general before
> specific. OReilly::* might be a whole family of site-
> specific modules.
Policy::* is *guaranteed* to be a large family of site-specific modules,
hopefully even larger than th
> > You Americans and your non-ISO penchant for putting the specific before
> > the general. Surely that should be:
> >
> > use Policy::O::Reilly;
>
> I knew someone would argue that, but I didn't think it would
> be someone as illustrious as Damian.
Illustrious???
Damian Conway wrote:
> You Americans and your non-ISO penchant for putting the specific before
> the general. Surely that should be:
>
> use Policy::O::Reilly;
I knew someone would argue that, but I didn't think it would
be someone as illustrious as Damian.
Do you think Larry doesn't kn
On Sun, 29 Apr 2001, Michael G Schwern wrote:
> Unfortunately, the perl6-language archive doesn't seem to go back far
> enough to cover the .perlrc discussion. Is the old archive still
> around?
don't know which archive you are talking about, but
http://archive.develooper.com/perl6-language%40p
On Sun, Apr 29, 2001 at 12:20:42PM -0700, Ask Bjoern Hansen wrote:
> don't know which archive you are talking about, but
> http://archive.develooper.com/perl6-language%40perl.org/ should have
> all mails sent to perl6-language from it's start to a few days ago
> when I moved stuff around.
I think
On Sun, Apr 29, 2001 at 12:49:28PM -0400, Dan Sugalski wrote:
> At 05:37 PM 4/29/2001 +0100, Michael G Schwern wrote:
> >By "optional" I take it you mean an admin can choose to define their
> >own site policy or not?
>
> No. Optional in that you have to do a "use SomePolicyThingWeHaventDecided;"
At 05:37 PM 4/29/2001 +0100, Michael G Schwern wrote:
>On Sun, Apr 29, 2001 at 11:44:24AM -0400, Dan Sugalski wrote:
> > At 04:30 PM 4/29/2001 +0100, Michael G Schwern wrote:
> > >To use a Perl 5 example, consider the simple setting of "use strict"
> > >as a general site policy. Basicaly, most of
On Sun, Apr 29, 2001 at 11:44:24AM -0400, Dan Sugalski wrote:
> At 04:30 PM 4/29/2001 +0100, Michael G Schwern wrote:
> >To use a Perl 5 example, consider the simple setting of "use strict"
> >as a general site policy. Basicaly, most of the Perl code in your
> >/usr/bin will explode when you try
At 04:30 PM 4/29/2001 +0100, Michael G Schwern wrote:
>On Sat, Apr 28, 2001 at 02:44:17PM -0400, Dan Sugalski wrote:
> > Well, I was thinking that generally the site policy would be expressed
> in a
> > single file
>
>This smells strangely familiar. Alot like the .perlrc discussion that
>was had
On Sat, Apr 28, 2001 at 02:44:17PM -0400, Dan Sugalski wrote:
> Well, I was thinking that generally the site policy would be expressed in a
> single file
This smells strangely familiar. Alot like the .perlrc discussion that
was had back many moons ago. The havoc a general syntax-altering
polic
At 03:44 PM 4/28/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: I hadn't really considered having a separate module for each type of site
>: policy decision.
>
>Er, neither had I. Each site only has one policy file. I just want it
>named after the actual site, not some generic name like
Dan Sugalski writes:
: I hadn't really considered having a separate module for each type of site
: policy decision.
Er, neither had I. Each site only has one policy file. I just want it
named after the actual site, not some generic name like "Policy". I
think policy files are inherently non-p
At 01:51 PM 4/27/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Besides, having the site administrator forbid the installation of parser
>: tweaks might not be what is wanted. If we get PPython in there, a site may
>: well have a Python.pm module handy, and source might start:
>:
>:use
[EMAIL PROTECTED] writes:
:> use OReilly::Policy;
:>
:> or
:>
:> use Mongolian::Navy::ProcurementOffice::Policy;
:>
:> might be more in order.
:
: You Americans and your non-ISO penchant for putting the specific before
: the general. Surely that should be:
:
> I think we have to be careful here. We should ask people to name site
> policy files after their site, and not use a generic name like
> "site_policy", since we'd be likely to end up with 20 different
> "standard" site_policy files wandering around the net. So something
> like
Dan Sugalski writes:
: Besides, having the site administrator forbid the installation of parser
: tweaks might not be what is wanted. If we get PPython in there, a site may
: well have a Python.pm module handy, and source might start:
:
:use site_policy qw(Python);
:
: for modules that wer
At 01:16 PM 4/27/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: It's also the one reason that I really like the idea of policy files of
>: some sort, to allow sites that don't want this sort of thing to forbid it.
>: I'm not talking things like perl automagically loading policy files in.
>
John Porter writes:
: Larry Wall wrote:
: > On the other hand, people don't generally declare which dialect they're
: > going to speak in before they start speaking.
:
: On the other other hand, perl already embraces the philosophy
: of pre-declaring things that change the language. That's wha
Larry Wall wrote:
> On the other hand, people don't generally declare which dialect they're
> going to speak in before they start speaking.
On the other other hand, perl already embraces the philosophy
of pre-declaring things that change the language. That's what
a pragma is. Even "my" could
Dan Sugalski writes:
: It's also the one reason that I really like the idea of policy files of
: some sort, to allow sites that don't want this sort of thing to forbid it.
: I'm not talking things like perl automagically loading policy files in.
: Rather having "use site_policy;" set limits tha
At 09:16 AM 4/27/2001 -0400, Eric Roode wrote:
>Larry Wall wrote:
>
>[wrt multiple syntaxes for Perl 6]
> >
> >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 t
At 04:19 PM 4/26/2001 -0700, Larry Wall wrote:
>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,
>: b
Larry Wall wrote:
[wrt multiple syntaxes for Perl 6]
>
>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
As a member of a con
On Thu, Apr 26, 2001 at 11:04:33PM -0500, Jarkko Hietaniemi wrote:
> 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 u
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
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 shap
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 do
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)
P
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,
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 somethin
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
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
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 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
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
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
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
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
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
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
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: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
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
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. W
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
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
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
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 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
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
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
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
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, 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
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.
At 09:06 PM 4/24/2001 -0700, Larry Wall wrote:
>Edward Peschko writes:
>: 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.
I was teaching an intro class yesterday and as usual, there were
Larry Wall wrote:
> (And juxtaposition is out because we're not going to destroy indirect
> object syntax
How often is indirect object syntax used without some whitespace? Having
the perl5->perl6 converter locate it and insert a space shouldn't be too
very tricky.
$these=$this$that$the_
Edward Peschko writes:
: 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.
Larry
On Tue, Apr 24, 2001 at 06:39:09PM -0700, 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
On Tue, Apr 24, 2001 at 06:54:18PM -0700, Larry Wall wrote:
> Nick Ing-Simmons writes:
> : Larry Wall <[EMAIL PROTECTED]> writes:
> : >I think using overloading to write a parser is going to be a relic of
> : >Perl 5's limitations, not Perl 6's.
> :
> : I am _NOT_ using overloading to write a par
Nick Ing-Simmons writes:
: Larry Wall <[EMAIL PROTECTED]> writes:
: >I think using overloading to write a parser is going to be a relic of
: >Perl 5's limitations, not Perl 6's.
:
: I am _NOT_ using overloading to write a parser.
: Parse::Yapp is just fine for writing parsers. I am trying to re-
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) means
: potentially having to move all the vtables
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 $hashref{ }.
Larry
> I still think it's a good idea - better than any other proposed so far.
>
> Are we so afraid of a little mandatory disambiguating white space
> that we are willing to pay the price of contorting other syntax
> beyond the bounds of sanity? :-)
>
> It's perfectly obvious to me that
>
> $x
On Tue, 24 Apr 2001, Michael G Schwern wrote:
> On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> > I think someone may have mentioned this already, but why not just say
> > that if you want '.' to mean concatenation, you have to surround it on
> > either side with white space?
Michael G Schwern wrote:
>
> On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
> > ok, well.. I've heard arguments for '+' (namely that its intuitive, other
> > language compatible, etc...) so what are the arguments against it?
>
> This one seems to have slipped by...
> http://arch
On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
> ok, well.. I've heard arguments for '+' (namely that its intuitive, other
> language compatible, etc...) so what are the arguments against it?
This one seems to have slipped by...
http://archive.develooper.com/perl6-language%40per
> ok, well.. I've heard arguments for '+' (namely that its intuitive, other
> language compatible, etc...) so what are the arguments against it?
Well, it looks like I'm a little bit behind. Spend 15 minutes typing something,
and you get 7 messages in your mailbox on the exact topic that you had
On Tue, Apr 24, 2001 at 05:44:49PM +0100, Michael G Schwern wrote:
> On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> > I think someone may have mentioned this already, but why not just say
> > that if you want '.' to mean concatenation, you have to surround it on
> > either side
On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
:
: On Tue, 24 Apr 2001, Graham Barr wrote:
:
: > On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:
: >
: > > At the moment I'm leaning toward ^ for concat, and ~ for xor. That
: >
: > I think that would lead to confusio
On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> I think someone may have mentioned this already, but why not just say
> that if you want '.' to mean concatenation, you have to surround it on
> either side with white space? If there's no white space around it, then
> it is force
On Tue, 24 Apr 2001, Graham Barr wrote:
> On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:
>
> > At the moment I'm leaning toward ^ for concat, and ~ for xor. That
>
> I think that would lead to confusion too. In many languages ^ is
> xor and ~ is a bitwise invert. It is that way i
On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:
> At the moment I'm leaning toward ^ for concat, and ~ for xor. That
> will help with ^= not resembling =~, though ~= would still mean The
> Wrong Thing...
As has been mentioned by others, ^ has established meaning in other
programming
Simon Cozens wrote:
> Let's put it a different way - if we can find a short operator which
> is readily accessible on most people's keyboards, then that would
> score over a longer operator which is readily accessible on most
> people's keyboards. Maybe ~ isn't that operator. Maybe & is, or ^ or
On Tue, Apr 24, 2001 at 12:29:23AM -0700, Russ Allbery wrote:
> How do you concatenate together a list of variables that's longer than one
> line without using super-long lines?
join '', $var1, $var2, $var3, ..., $varN;
TMTOWTDI, remember.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Tue, 24 Apr 2001 14:37:02 +0100, Simon Cozens wrote:
>Let's put it a different way - if we can find a short operator which
>is readily accessible on most people's keyboards, then that would
>score over a longer operator which is readily accessible on most
>people's keyboards. Maybe ~ isn't th
At 09:33 AM 4/24/2001 -0400, 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 a
On Tue, Apr 24, 2001 at 03:26:04PM +0200, Henrik Tougaard wrote:
> > From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> > On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> > > Please don't use the keypresscount as an argument.
> > Why not? We're making easy things easy, remember.
> B
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.
--
John Porter
At 02:55 AM 4/24/2001 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > It wouldn't be all that tough to change this if you were so inclined--it'd
> > certainly be a simpler parser modification than some others that have been
> > proposed.
>
>Yes, I hadn't thought of that. Yay again.
The one do
> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> > Please don't use the keypresscount as an argument.
>
> Why not? We're making easy things easy, remember.
>
Because your keyboard layout isnt mine! I have nice letters like
'æ',
On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> On my keyboard '~' is 3 keystrokes - and rather complicated ones
> at that:
Then maybe ~ isn't best.
> Please don't use the keypresscount as an argument.
Why not? We're making easy things easy, remember.
--
Rule 3: If the char
Larry Wall <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons writes:
>: >You really have to talk about overloading boolean context
>: >in general.
>:
>: Only if you are going to execute the result in the normal perl realm.
>: Consider using the perl parser to build a parse tree - e.g. one to
>: read
> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> > Make concatination be "$a cat $b". ("eq" and friends
> already provide
> > precedent for string operators being words rather than symbols.)
>
> While that's true, concatenation is quite a common operation
> (Introspection
> is cool. Run "perl
On Tue, 24 Apr 2001 10:49:18 +0100, Simon Cozens wrote:
>While that's true, concatenation is quite a common operation
>that I'd be really
>uncomfortable with it necessitating 4 keystrokes (" cat") instead of one.
Er, "~" is an extremely annoying character to type at many keyboards. It
may depen
On Tue, Apr 24, 2001 at 02:01:11AM -0700, Damien Neil wrote:
> If you're dead-set on reassigning ., please consider leaving it at
> that, rather than juggling all the other operators around.
Don't forget that binary ~ doesn't currently exist, so this is adding
syntax rather than reassigning it.
On 24 Apr 2001 00:29:23 -0700, Russ Allbery wrote:
>How do you concatenate together a list of variables that's longer than one
>line without using super-long lines? Going to the shell syntax of:
>
>PATH=/some/long:/bunch/of:/stuff
>PATH="${PATH}:/more/stuff"
>
>would really be a shame.
On Mon, Apr 23, 2001 at 11:31:18AM -0700, Larry Wall wrote:
> There are many people who would prefer . to ->, if for no other reason
> than it's cleaner looking and is one less character to type. The fact
> that it's become the industry standard for method call syntax is also
> a point in its fav
1 - 100 of 189 matches
Mail list logo
