Re: Tying & Overloading

2001-05-09 Thread Michael G Schwern
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

Re: Tying & Overloading

2001-05-09 Thread Austin Hastings
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

Re: Tying & Overloading

2001-05-09 Thread nick
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-05-09 Thread nick
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

Re: Tying & Overloading

2001-05-01 Thread Dan Sugalski
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

Re: Tying & Overloading

2001-04-30 Thread Dan Sugalski
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

Re: Tying & Overloading

2001-04-30 Thread Kai Henningsen
[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

Re: Tying & Overloading

2001-04-30 Thread Larry Wall
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-30 Thread Tim Bunce
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-29 Thread David L. Nicol
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 >

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread ashley
> 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

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread John Porter
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread Simon Cozens
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread Damian Conway
> > 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???

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread John Porter
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread Ask Bjoern Hansen
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread Michael G Schwern
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread Michael G Schwern
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;"

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread Dan Sugalski
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread Michael G Schwern
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread Dan Sugalski
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread Michael G Schwern
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-29 Thread Dan Sugalski
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-28 Thread Larry Wall
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-28 Thread Dan Sugalski
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-28 Thread Larry Wall
[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: :

Re: Flexible parsing (was Tying & Overloading)

2001-04-28 Thread Damian Conway
> 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

Re: Flexible parsing (was Tying & Overloading)

2001-04-27 Thread Larry Wall
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-27 Thread Dan Sugalski
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. >

Re: Flexible parsing (was Tying & Overloading)

2001-04-27 Thread Larry Wall
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-27 Thread John Porter
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-27 Thread Larry Wall
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-27 Thread Dan Sugalski
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-27 Thread Dan Sugalski
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-27 Thread Eric Roode
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-27 Thread Nicholas Clark
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-26 Thread Jarkko Hietaniemi
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-26 Thread Simon Cozens
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-26 Thread Jarkko Hietaniemi
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-26 Thread Larry Wall
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-26 Thread Larry Wall
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,

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-26 Thread Larry Wall
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-26 Thread Bart Lateur
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

Re: Tying & Overloading

2001-04-25 Thread Andy Dougherty
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

Re: Tying & Overloading

2001-04-25 Thread Dan Sugalski
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

Re: Tying & Overloading

2001-04-25 Thread Dan Sugalski
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-25 Thread Graham Barr
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

Re: Tying & Overloading

2001-04-25 Thread Dan Sugalski
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-25 Thread Simon Cozens
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

Re: Tying & Overloading

2001-04-25 Thread Branden
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-25 Thread Eric Roode
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

Re: Flexible parsing (was Tying & Overloading)

2001-04-25 Thread Dan Sugalski
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

Re: Tying & Overloading

2001-04-25 Thread Jonathan Scott Duff
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

Re: Tying & Overloading

2001-04-25 Thread Branden
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-25 Thread Eric Roode
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

Re: Tying & Overloading

2001-04-25 Thread James Mastros
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

Re: Tying & Overloading

2001-04-25 Thread Branden
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-25 Thread Randal L. Schwartz
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

Re: Tying & Overloading

2001-04-25 Thread Branden
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

Re: Tying & Overloading

2001-04-25 Thread Bart Lateur
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-

Re: Tying & Overloading

2001-04-25 Thread Dan Sugalski
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-25 Thread Larry Wall
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-25 Thread Larry Wall
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

Re: Tying & Overloading

2001-04-25 Thread Simon Cozens
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-25 Thread Bart Lateur
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-25 Thread Bart Lateur
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-25 Thread David L. Nicol
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.

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Peter Scott
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

Re: Tying & Overloading

2001-04-24 Thread David L. Nicol
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_

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Larry Wall
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Edward Peschko
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

Re: Tying & Overloading

2001-04-24 Thread Edward Peschko
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

Re: Tying & Overloading

2001-04-24 Thread Larry Wall
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-

Re: Tying & Overloading

2001-04-24 Thread Larry Wall
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Larry Wall
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Edward Peschko
> 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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread John L. Allen
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?

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Nathan Wiger
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Michael G Schwern
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Edward Peschko
> 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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Edward Peschko
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Casey West
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Michael G Schwern
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread John L. Allen
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Jonathan Scott Duff
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

Re: Tying & Overloading

2001-04-24 Thread John Porter
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

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Jonathan Scott Duff
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]

Re: Tying & Overloading

2001-04-24 Thread Bart Lateur
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

Re: Tying & Overloading

2001-04-24 Thread Dan Sugalski
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

Re: Tying & Overloading

2001-04-24 Thread Simon Cozens
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

Re: Tying & Overloading

2001-04-24 Thread John Porter
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

Re: Tying & Overloading

2001-04-24 Thread Dan Sugalski
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

RE: Tying & Overloading

2001-04-24 Thread Henrik Tougaard
> 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 'æ',

Re: Tying & Overloading

2001-04-24 Thread Simon Cozens
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

Re: Tying & Overloading

2001-04-24 Thread Nick Ing-Simmons
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

RE: Tying & Overloading

2001-04-24 Thread Henrik Tougaard
> 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

Re: Tying & Overloading

2001-04-24 Thread Bart Lateur
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

Re: Tying & Overloading

2001-04-24 Thread Simon Cozens
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.

Re: Strings vs Numbers (Re: Tying & Overloading)

2001-04-24 Thread Bart Lateur
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.

Re: Tying & Overloading

2001-04-24 Thread Damien Neil
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   2   >