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 should be
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');
# ordered:
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 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 complexity of a separate
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 bad
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 asking if the
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];
This is an argument against
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 @bar
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 single
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 why is that
@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 [] and {}.
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
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 was
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 out (I
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!)
--
Bart.
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
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* after
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]
would mean:
(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 scientific
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 easy. Just
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 much as I
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 were
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:
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*.
nice save
p
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
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.
--
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
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
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 going to be a
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
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 it
-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 @ and % would be a perl6 design win?
Nope, I still
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 scalars already.
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 numbers.
Different
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 all
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,
: 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 strings
snip
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
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.
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.
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 references
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. Thus they
[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
strings,
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
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,
until
snip
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, though not
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 references.
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
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
most common).
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
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 Hungarian
-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, and % is a
multiplicity of pairs
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
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 around
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
[...] 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
Simon Cozens wrote:
A scalar's a thing.
Just as the index into a multiplicity is a thing.
--
John Porter
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
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
Graham.
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,
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) {
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
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
push chairs, map {woodworking} treestumps;
or even
push chairs, map BLOCK(woodworking) treestumps;
65 matches
Mail list logo
