Me wrote:
>
> It was an informal finger-in-the-wind thing I sent to
> a perl beginners list. Nothing special, just a quick
> survey.
>
> http://www.self-reference.com/cgi-bin/perl6plurals.pl
>
> > I certainly do not see that many people on the
> > list agreeing with you.
>
> And that means I s
On Mon, May 14, 2001 at 05:16:34PM -0400, John Porter wrote:
> Simon Cozens wrote:
> > I'm not telling you how it *looks* in Perl 5, I'm telling you (in Perl 5
> > terms) what it will *mean*.
>
> Fine, you're using perl5 as pseudocode.
> I could do that too. But it has no bearing on the
> desira
> On Mon, May 14, 2001 at 04:50:17PM -0400, John Porter wrote:
> > Pardon my indelicacy, but - Screw how it looks in Perl5.
>
> I'm not telling you how it *looks* in Perl 5, I'm telling you (in Perl 5
> terms) what it will *mean*.
nice save
p
Simon Cozens wrote:
> I'm not telling you how it *looks* in Perl 5, I'm telling you (in Perl 5
> terms) what it will *mean*.
Fine, you're using perl5 as pseudocode.
I could do that too. But it has no bearing on the
desirability of anyone's proposed perl6 syntax or
semantics.
--
John Porter
On Mon, May 14, 2001 at 04:50:17PM -0400, John Porter wrote:
> Pardon my indelicacy, but - Screw how it looks in Perl5.
I'm not telling you how it *looks* in Perl 5, I'm telling you (in Perl 5
terms) what it will *mean*.
--
Use an accordion. Go to jail.
-- KFOG, San Francisco
Simon Cozens wrote:
> It's really, really easy. Just stick a -> between the variable and
> the brace, and you have Perl 5.
Pardon my indelicacy, but - Screw how it looks in Perl5.
We can make it mean anything, and appear anyhow we want.
IOW, "what makes sense" in Perl6 isn't defined by how
we wer
Edward Peschko wrote:
> > As to what the combined
> >
> > $bar[$foo]
> >
> > would mean: that depends on what $bar contains.
> >
> I like visual clues to tell me
> what type of variable
> something is. And I disagree strongly with trying to
> steamroller the language's
> design paper-flat as
On Mon, May 14, 2001 at 08:38:31PM +0100, Graham Barr wrote:
> > What is the meaning of the following four expressions in Perl6?
> > @bar[$foo];
> > %bar{$foo};
> > @bar{$foo};
> > %bar[$foo];
> $bar[$foo];
> $bar{$foo};
It's really, really e
> (i.e. ordered or "associative").
A (probably futile, but one has to try) plea for
people to use "numbered" rather than "ordered".
@foo = ['England', 'France', 'Germany'];# unordered
%foo = {First => Fred', Last => 'Bloggs']; # ordered
(I'd also suggest "named" instead of the scie
On Mon, May 14, 2001 at 10:11:01PM +0200, Bart Lateur wrote:
> On Mon, 14 May 2001 20:38:31 +0100, Graham Barr wrote:
>
> >You forgot
> >
> > $bar[$foo]; # $bar is an array reference
> > $bar{$foo}; # $bar is a hash reference
>
> As to what the combined
>
> $bar[$foo]
>
>
> As someone else pointed out (I forget who). But beginners are not
> always the best people to ask. Beginner don't stay beginners for
> long I think the quote was.
And as I said before, I agree.
I picked the beginners list as much because it was
active as anything else. They are *somebody* afte
Bart Lateur wrote:
> As to what the combined
> $bar[$foo]
> would mean: that depends on what $bar contains.
I think it would depend on what the declared type
of @bar was (i.e. ordered or "associative").
--
John Porter
On Mon, 14 May 2001 20:38:31 +0100, Graham Barr wrote:
>You forgot
>
> $bar[$foo]; # $bar is an array reference
> $bar{$foo}; # $bar is a hash reference
As to what the combined
$bar[$foo]
would mean: that depends on what $bar contains.
(Aw! That hurt!)
--
Bar
On Mon, May 14, 2001 at 02:51:08PM -0500, Me wrote:
> > survey ? I never saw any survey,
>
> It was an informal finger-in-the-wind thing I sent to
> a perl beginners list. Nothing special, just a quick
> survey.
>
> http://www.self-reference.com/cgi-bin/perl6plurals.pl
As someone else pointed
On Mon, May 14, 2001 at 03:58:31PM -0400, John Porter wrote:
> Graham Barr wrote:
> > As I said in another mail, consider
> > $bar[$foo];
> > $bar{$foo};
>
> But if @bar is known to be one kind of array or
> the other, where is the ambiguosity that that is
> meant to avoid?
I did not say it
Graham Barr said:
> I am not interested in continuing this in private.
As you wish.
> If you don't want your comments public then be quite.
I thought it was best for the list if we had some private
exchanges first to reduce noise. I'll try to remember
that you don't like that approach.
> surv
Graham Barr wrote:
> As I said in another mail, consider
> $bar[$foo];
> $bar{$foo};
But if @bar is known to be one kind of array or
the other, where is the ambiguosity that that is
meant to avoid?
--
John Porter
> > @bar[$foo]; # A
> > %bar{$foo}; # B
> > @bar{$foo}; # C
> > %bar[$foo]; # D
> >
> You forgot
>
> $bar[$foo]; # $bar is an array reference
> $bar{$foo}; # $bar is a hash reference
I can't argue with that.
My vote is now against conflating []
On Mon, May 14, 2001 at 03:41:24PM -0400, John Porter wrote:
> Damian Conway wrote [and John Porter reformats]:
> >
> > @bar[$foo]; # Access element int($foo) of array @bar
> > %bar{$foo}; # Access entry "$foo" of hash %bar
> > @bar{$foo}; # Syntax error
> > %bar[$foo]; # Syntax error
>
> And w
> When all the smoke clears, it will be relatively simple to declare an
> ordered hash probably on the order of adding a single word to its
> declaration.
Yep. In fact, it's now relatively simple in Perl 5.
You just grab the Attribute::Handlers and Tie::SortHash modules and
add a sing
Damian Conway wrote [and John Porter reformats]:
>
> @bar[$foo]; # Access element int($foo) of array @bar
> %bar{$foo}; # Access entry "$foo" of hash %bar
> @bar{$foo}; # Syntax error
> %bar[$foo]; # Syntax error
And why is that superior to:
@bar[$foo]; # Access element int($foo) of array @b
On Mon, May 14, 2001 at 03:23:56PM -0400, Buddha Buck wrote:
> At 08:10 PM 05-14-2001 +0100, Graham Barr wrote:
> >On Mon, May 14, 2001 at 01:56:01PM -0500, Me wrote:
> > > > Hm, OK. What does this access and using what method ?
> > > >
> > > > $foo = '1.2';
> > > > @bar[$foo];
> > >
> > > Thi
I'm not buying into the argument...just providing data:
> What is the meaning of the following four expressions in Perl6?
>
> @bar[$foo]; # A
Access element int($foo) of array @bar
> %bar{$foo}; # B
Access entry "$foo" of hash %bar
> @bar{$foo}; # C
At 08:10 PM 05-14-2001 +0100, Graham Barr wrote:
>On Mon, May 14, 2001 at 01:56:01PM -0500, Me wrote:
> > > Hm, OK. What does this access and using what method ?
> > >
> > > $foo = '1.2';
> > > @bar[$foo];
> >
> > This is an argument against conflating @ and %.
>
>No it is not.
>
> > It has no
On Mon, May 14, 2001 at 01:56:01PM -0500, Me wrote:
> > Hm, OK. What does this access and using what method ?
> >
> > $foo = '1.2';
> > @bar[$foo];
>
> This is an argument against conflating @ and %.
No it is not.
> It has nothing to do with using [] instead of {}.
Yes it does. I was aski
> Hm, OK. What does this access and using what method ?
>
> $foo = '1.2';
> @bar[$foo];
This is an argument against conflating @ and %.
It has nothing to do with using [] instead of {}.
(I accept that the @/% issue is problematic. Otoh,
I don't yet see @/% conflation as being obviously
a b
On Mon, May 14, 2001 at 12:32:37PM -0500, Me wrote:
> > an ordered hash is common
>
> Arrays too.
>
>
> > not wise ... to alter features just for beginners.
>
> Agreed.
>
>
> > (PS 11 people isn't a statistic, its a night at the pub)
>
> Your round...
>
>
> The extra complexi
> an ordered hash is common
Arrays too.
> not wise ... to alter features just for beginners.
Agreed.
> (PS 11 people isn't a statistic, its a night at the pub)
Your round...
The extra complexity of a separate hash syntax might
be justified for other reasons, but not the ones
On Sun, May 13, 2001 at 11:37:01PM -0500, Me wrote:
> Yes. But I'm not sure that:
>
> # ordered
> @array = (1, 2, 3, 5, 8);
>
> # unordered
> %hash = (Fred => 22, Jane => 30);
>
> is more or less typical than:
>
> # unordered:
> @array = ('England', 'France', 'Germany');
>
Larry,
No need to respond to individual points, because you
are so clearly wrong. ;> But I would appreciate an
overall response of something like either "this ain't
happening, so give up" or "it remains a possibility,
but I'm not yet remotely convinced". Thanks for your
continued forbearance.
>
Me writes:
: Larry:
: > : > Currently, @ and [] are a promise that you don't intend to use
: string
: > : > indexing on this variable. The optimizer can make good use of
: this
: > : > information. For non-tied arrays of compact intrinsic types, this
: > : > is going to be a major performance wi
Larry:
> : > Currently, @ and [] are a promise that you don't intend to use
string
> : > indexing on this variable. The optimizer can make good use of
this
> : > information. For non-tied arrays of compact intrinsic types, this
> : > is going to be a major performance win in Perl 6.
Clearly the
> : Assuming that optimization opportunities remained intact,
>
> They won't, but go on.
Because the syntax won't provide the compiler enough info?
> : do you think conflating @ and % would be a perl6 design win?
>
> Nope, I still think most ordinary people want different
> operators for stri
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> On Thu, May 10, 2001 at 11:57:54AM -0400, John Porter wrote:
> >
> > Makes sense to have it for containers indexed by scalar as well.
>
> I'll say it again for the l^W^W^W - arrays and hashes are conceptually
> very different beasts.
strings,
On Thu, May 10, 2001 at 01:51:25PM -0500, Garrett Goebel wrote:
> > I'll say it again for the l^W^W^W - arrays and hashes are conceptually
> > very different beasts.
>
> strings, integers, longs, and floats are conceptually very different beasts.
No, not really. Integers, longs and floats are al
On Thu, May 10, 2001 at 12:43:13PM -0500, David L. Nicol wrote:
> John Porter wrote:
> >
> > Larry Wall wrote:
> > >
> > > : do you think conflating @ and % would be a perl6 design win?
> > >
> > > Nope, I still think most ordinary people want different operators for
> > > strings than for number
John Porter wrote:
>
> Larry Wall wrote:
> >
> > : do you think conflating @ and % would be a perl6 design win?
> >
> > Nope, I still think most ordinary people want different operators for
> > strings than for numbers.
>
> Different operators, conflated data type.
>
> That's what we have for s
On Thu, May 10, 2001 at 11:57:54AM -0400, John Porter wrote:
> Makes sense to have it for containers indexed by scalar as well.
I'll say it again for the l^W^W^W - arrays and hashes are conceptually
very different beasts.
Shopping list, phone book. Different things.
--
The man who sees, on New
> -Original Message-
> From: John Porter [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 10, 2001 11:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: what I meant about hungarian notation
>
>
> Larry Wall wrote:
> >
> > : do you think conflating
Larry Wall wrote:
>
> : do you think conflating @ and % would be a perl6 design win?
>
> Nope, I still think most ordinary people want different operators for
> strings than for numbers.
Different operators, conflated data type.
That's what we have for scalars already.
Makes sense to have i
> Nope, I still think most ordinary people want different operators for
> strings than for numbers. Dictionaries and calculators have very
> different interfaces in the real world, and it's false economy to
> overgeneralize. Witness the travails of people trying to use
> cell phones to type mess
Larry Wall <[EMAIL PROTECTED]> writes:
> Me writes:
> : Larry:
> : > Currently, @ and [] are a promise that you don't intend to use string
> : > indexing on this variable. The optimizer can make good use of this
> : > information. For non-tied arrays of compact intrinsic types, this
> : > is go
Me writes:
: Larry:
: > Currently, @ and [] are a promise that you don't intend to use string
: > indexing on this variable. The optimizer can make good use of this
: > information. For non-tied arrays of compact intrinsic types, this
: > is going to be a major performance win in Perl 6.
:
: As
Hillary writes:
: >I happen to like $ and @. They're not going away in standard Perl as
: >long as I have anything to do with it. Nevertheless, my vision for Perl
: >is that it enable people to do what *they* want, not what I want.
: >
: >Larry
:
: If only that were true...But it isn't true. It
Larry:
> Currently, @ and [] are a promise that you don't intend to use string
> indexing on this variable. The optimizer can make good use of this
> information. For non-tied arrays of compact intrinsic types, this
> is going to be a major performance win in Perl 6.
Assuming that optimization
>I happen to like $ and @. They're not going away in standard Perl as
>long as I have anything to do with it. Nevertheless, my vision for Perl
>is that it enable people to do what *they* want, not what I want.
>
>Larry
If only that were true...But it isn't true. It was never true. And you
knew
>Does that mean we can nuke Redmond and move on to reality in corporate IS
>now?
That must never happen. It can be stopped. It must be stopped. It will be
stopped.
(except for the Redmond part, which I suspect might be a bit hard on
*their* eyes)
Hillary
"You're nothing if not dramatic."
Bart Lateur wrote:
>
> So what you're saying is that references aren't really scalars,
> but their own type. Thus they need their own prefix.
>
> But we've sort of run out of possible prefixes.
that is my interpretation of the p4->p5 decision to make references
fit within the scalar type; which
David Grove wrote:
...
> This is frightening me too. I really don't like the thought of
>
> $i = "1.0";
> $i += 0.1 if $INC;
> $i .= " Foo, Inc.";
>
> (or more specifically a one line version that converts several times for a
> single statement)
>
> becoming
>
> my str $i = "1.0";
> if($INC)
On Wed, May 09, 2001 at 02:04:40PM -0400, John Porter wrote:
> Simon Cozens wrote:
> > A scalar's a thing.
> Just as the index into a multiplicity is a thing.
Indeed, hashes have scalar keys. Did you not realise that I conveyed
the same information in amazingly less confusing terminology?
Again
On Wed, May 09, 2001 at 02:04:40PM -0400, John Porter wrote:
> Simon Cozens wrote:
> > A scalar's a thing.
>
> Just as the index into a multiplicity is a thing.
Yes, but as Larry pointed out. Knowing if the index is to be treated
as a number or a string has some advantages for optimization
Gra
David Grove wrote:
> something similar to PHP's Array['text'] notation.
(I think awk, but whatever...)
my @collection is associative;
> since these will become actual objects in Perl 6,
> *how* they are indexed could be a simple flag
Or, in fact, any user-defined scheme.
> The re
Simon Cozens wrote:
> A scalar's a thing.
Just as the index into a multiplicity is a thing.
--
John Porter
> [...] subject to ethnic
> cleansing. Culture wars arise spontaneously, but that should not deter
> us from enabling people to build new cultures. [...]
Does that mean we can nuke Redmond and move on to reality in corporate IS
now?
};P
David Grove writes:
: Probably rehashing (no pun intended) a lost cause, but this sounds logical
: to me, if you're referring to something similar to PHP's Array['text']
: notation. I.e.,
:
: $array[1]
: $hash{'one'}
:
: becoming
:
: @group['one']
Currently, @ and [] are a promise that you don
On Wed, May 09, 2001 at 09:58:44AM -0700, Larry Wall wrote:
> I'd just like to point out that it's already becoming fairly easy
> to establish a bare alias for a scalar variable even in Perl 5:
>
> my $foo;
> my sub foo : lvalue { $foo }
I tried working on a "pythonish" module built arou
I'd just like to point out that it's already becoming fairly easy
to establish a bare alias for a scalar variable even in Perl 5:
my $foo;
my sub foo : lvalue { $foo }
This sort of thing will only get easier in Perl 6, when people can pull
in their own grammatical rules to enable them to
> -Original Message-
> From: John Porter [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 09, 2001 11:51 AM
> To: [EMAIL PROTECTED]
> Subject: Re: what I meant about hungarian notation
>
>
> David Grove wrote:
> > $ is a singularity, @ is a multiplicity
> > But $, @, and % indicate data organization, not type...
>
> Actually they do show "type", though not in a traditional sense.
> Organization <-> type is semantic oddery, but they do keep our heds
straight
> about what's in the variable.
Sure. But my point was that Perl's use of $ isn't Hungari
On Wed, May 09, 2001 at 11:51:14AM -0400, John Porter wrote:
> Actually, % is also simply a multiplicity, differentiated only
> by the semantics of its indexing.
Bah. You should try teaching this stuff! :)
A scalar's a thing. An array's a line of things. A hash is a bag of
pairs of things.
All
On Wed, 9 May 2001 11:06:45 -0400, Bryan C. Warnock wrote:
>>At that
>> point, Hungarian notation fell apart for me. Its strict use adds (IMO) as
>> much confusion as MicroSoft's redefinition of C, with thousands of
>> typedefs representing basic types ("LPSTR" and "HWND" come to mind as the
>> m
David Grove wrote:
> $ is a singularity, @ is a multiplicity, and % is a multiplicity of pairs
> with likely offspring as a result. ;-)
Actually, % is also simply a multiplicity, differentiated only
by the semantics of its indexing.
Which is why I argued, some time back, in favor of conflating
a
On Tue, May 08, 2001 at 08:21:10PM -0500, David L. Nicol wrote:
> What if, instead of cramming everything into "scalar" to the point
> where it loses its value as "a data type that magically converts
> between numeric and string, as needed," we undo the Great Perl5
> Dilution and undecorate refere
On Wednesday 09 May 2001 10:44, David Grove wrote:
> I used to request hungarian notation from programmers who worked for me,
> until I saw the actual compliance with that request culminate in a local
> variable named l_st_uliI. Of course, that's an "static unsigned int i"
> used as a simple itera
> >An object of type "abstracted reference to a chair" is _NOT_ an object of
> >type "numeric or string that magicly switches between as needed"
>
> So what you're really saying is that references aren't really scalars,
> but their own type. Thus they need their own prefix.
>
> But we've sort of r
On Wed, May 09, 2001 at 04:02:43PM +0200, Bart Lateur wrote:
> What he is proposing is that Perl6 would have a kind of variable that
> doesn't have a prefix. That isn't perlish IMO.
open OUT, ">foo" or die $!;
print OUT "Rubbish!\n";
close OUT;
OUT = STDERR; # Works in 5.7.1, I think.
(Incidenta
>
> > sane indentation by making it part of the language, Perl is a
> > language that enforces a dialect of hungarian notation by making
> > its variable decorations an intrinsic part of the language.
>
> But $, @, and % indicate data organization, not type...
Actually they do show "type", thoug
> Hungarian notation is any of a variety of standards for organizing
> a computer program by selecting a schema for naming your variables
> so that their type is readily available to someone familiar with
> the notation.
I used to request hungarian notation from programmers who worked for me,
unt
At 04:02 PM 5/9/2001 +0200, Bart Lateur wrote:
>What he is proposing is that Perl6 would have a kind of variable that
>doesn't have a prefix. That isn't perlish IMO.
Sure it is. DEC BASIC let you do that (drop prefixes on variables declared
with types) and stealing from other languages is very p
[on David Nicol's thought that maybe references should be treated
differently than other scalar data]
>
>But $, @, and % indicate data organization, not type...
>
Perhaps it's a mistake that Perl treats numbers and strings the
same. Perhaps "$" should be broken out into two prefixes: S for
string
On Wed, 9 May 2001 09:47:56 -0400, John Porter wrote:
>> Undecorated if for function calls and methods. And buolt-ins, of course.
>
>No, that's the situation already. David is proposing a change.
>
>> So what you're really saying is that references aren't really scalars,
>> but their own type. T
Bart Lateur wrote:
> David L. Nicol wrote:
> >we undo the Great Perl5
> >Dilution and undecorate references.
>
> Undecorated if for function calls and methods. And buolt-ins, of course.
No, that's the situation already. David is proposing a change.
> So what you're really saying is that refer
I really need to spell-check better.
>Undecorated if for function calls and methods. And buolt-ins, of course.
Undecorated is for function calls and methods. And built-ins, of course.
--
Bart.
On Tue, 08 May 2001 20:21:10 -0500, David L. Nicol wrote:
>What if, instead of cramming everything into "scalar" to the point
>where it loses its value as "a data type that magically converts
>between numeric and string, as needed," we undo the Great Perl5
>Dilution and undecorate references.
Un
> sane indentation by making it part of the language, Perl is a
> language that enforces a dialect of hungarian notation by making
> its variable decorations an intrinsic part of the language.
But $, @, and % indicate data organization, not type...
> What if, instead of cramming everything into
> push chairs, map {woodworking} treestumps;
>
or even
push chairs, map BLOCK(woodworking) treestumps;
Hungarian notation is any of a variety of standards for organizing
a computer program by selecting a schema for naming your variables
so that their type is readily available to someone familiar with
the notation.
Just as Python is a language that enforces the common practice of
sane indentatio
77 matches
Mail list logo
