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
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
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
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
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
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
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
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, 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
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
> 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
Bart Lateur <[EMAIL PROTECTED]> writes:
> My vote is to ditch the concat operator altogether. Hey, we have
> interpolation!
> "$this$is$just$as$ugly$but$it$works"
How do you concatenate together a list of variables that's longer than one
line without using super-long lines? Going to the
Graham Barr wrote:
> The other choice is not to have a concat operator but instead have
> C, but I guess not many people would like that either.
sub concat(@) { join '', @_ }
Seems to me like the sort of thing that ought to be in the core.
--
John Porter
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 requirement to predeclare all variables would come into p
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 in perl now too, so
perl is already quite standard in t
>I am not sure I do like the use of ~ here. It does not screan concatenate
to me (but then again neither did . when I started perl)
>I am thinking that maybe it should be a 2 character operator with at least
one of then being + as + is common in many other languages for doing
concatenation.
How
Bart Lateur writes:
: On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:
:
: >Using + for concat: no!
: >
: >My vote is to use . and require space before and after.
: >$this.$is.$ugly.$anyway ;)
:
: My vote is to ditch the concat operator altogether. Hey, we have
: interpolation!
:
:
At 04:46 PM 4/23/2001 -0400, John Porter wrote:
>Larry Wall wrote:
> > Except we're not having highlander variables. $foo and @foo remain
> > distinct entities.
>
>I know. Sad.
>
>(Of course, what I meant by highlander was no prefix chars.
>Highlanderishness is just a consequence of that.)
It w
On Mon, Apr 23, 2001 at 01:23:43PM -0600, Nathan Torkington wrote:
> Larry Wall writes:
> > wanted, you still get the length. If you're worried about the delayed
> > operation, you can force numeric context with $x = +@tmp;, just as you
> > can force string context with a unary ~.
>
> How often
Larry Wall writes:
> wanted, you still get the length. If you're worried about the delayed
> operation, you can force numeric context with $x = +@tmp;, just as you
> can force string context with a unary ~.
How often are you likely to do this? Speaking as a reader of code,
I've always hated una
Nathan Wiger wrote:
> I *really* don't want this to turn into a religious argument,
Neither do I.
> coming from a sh/C background.
I understand. I think I was able to learn Perl as quickly
as I did because of certain syntactic similarities.
But it's not why I program in Perl now, and it's c
Branden wrote:
> > Changing the semantics of Perl to make it more
> > powerful is something every perl programmer would be happy
> > about. Consequent changes to the syntax is something we
> > would live with.
>
> I don't see the semantic change to make it more powerful that is behind
> changin
John Porter wrote:
>
> > One of the reasons I program in Perl as my
> > primary language is *because of* the syntax.
>
> With all due respect, I don't believe that's why you,
> or anyone else, likes to program in Perl.
I *really* don't want this to turn into a religious argument, which it's
fas
At 04:40 PM 23/04/2001 -0400, John Porter wrote:
>Nathan Wiger wrote:
> > if you changed Perl's syntax too radically you
> > would almost certainly lose programmers.
>
>I disagree. Changing the semantics of Perl to make it more
>powerful is something every perl programmer would be happy
>about.
Larry Wall wrote:
> Except we're not having highlander variables. $foo and @foo remain
> distinct entities.
I know. Sad.
(Of course, what I meant by highlander was no prefix chars.
Highlanderishness is just a consequence of that.)
--
John Porter
Nathan Wiger wrote:
> if you changed Perl's syntax too radically you
> would almost certainly lose programmers.
I disagree. Changing the semantics of Perl to make it more
powerful is something every perl programmer would be happy
about. Consequent changes to the syntax is something we
would liv
On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:
>Using + for concat: no!
>
>My vote is to use . and require space before and after.
>$this.$is.$ugly.$anyway ;)
My vote is to ditch the concat operator altogether. Hey, we have
interpolation!
"$this$is$just$as$ugly$but$it$works"
At 04:14 PM 23/04/2001 -0400, John Siracusa wrote:
>On 4/23/01 3:59 PM, Nathan Wiger wrote:
> >> Then how do you concatenate a number?
>
>Using + for concat: no!
>
>My vote is to use . and require space before and after.
>$this.$is.$ugly.$anyway ;)
People who use one-liners know the value of $ugl
1 - 100 of 143 matches
Mail list logo
