Re: what I meant about hungarian notation
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 quiet? I hope not.
what I have written in the comments blank:
Suggestion:
retain complete perl5 syntax with the following
DWIM exceptions defined:
Accesses that would, in array context, currently amount
to a single-length slice, in an scalar context, become
that-value-but-true, for string and logic accesses, and
give a non-quietable (fatal, even?) warning on use in a
numeric (but not assignment for later use) context. That
takes care of
@containername[{key-expression}]
and
@containername{{key-expression}}
Also, redefine the wrong kind of brackets to
correct to the right kind of brackets instead
of autovivifying the other kind of container, when
the other kind of container does not exist already.
Which is pretty much exactly what got suggested later 5/14
Later, the first person objective pronoun intoned:
Suggestion: deprecate {}.
The benefit is saving {} for alternative/future perl use,
and the fact that beginners prefer [] as the subscript
parens for both arrays and hashes by a more than 2
to 1 margin.
One cost is that:
$foo[$bar]
would be syntactically ambiguous. The compiler
would know enough to deal, but humans would not.
and strict braces would kill you if you use the wrong
one, instead of letting you slide
Suggestion: deprecate both % and {}.
Benefits are both of the above.
Costs are numerous and deep.
how about flexiblize instead of deprecate?
how about keeping them but deprecate allowing by-number and by-name
to share the same glob?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
# die smiling;
Re: what I meant about hungarian notation
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:
%hash = (Name = 'Ralph',
You're right, the want of an ordered hash is common, but definately
not in the majority (and its quite a bit slower and eats more memory).
There have been numerous proposals for giving various easy ways to
declare the sort order for a hash. http://dev.perl.org/rfc/124.pod is
one. The idea of variable attributes is another.
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. Whipping up a storm about it is unnecessary.
11 normal people (perl beginners) have responded
to this so far.
While there is merit in taking beginners's needs into account, it is
not wise when designing a language to alter features just for
beginners. As elitist as this may sound, they are beginners and will
advocate short-term solutions. They don't quite know what works best
in the long run.
Also, I don't equate beginners with normal (perhaps loud). After
all, beginners don't stay beginners for long. For every beginner now
there will be one less in a year (either they've gotten better or
they're doing something else). The only new font of beginners is
brand-new programmers. Again, they should be taken into account and
the learning curve banked for speed as much as possible, but you don't
design a language around them.
For most of your programming life, you are not a beginner.
Anyhow, this is how you get things like BASIC.
(PS 11 people isn't a statistic, its a night at the pub)
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Maybe they hooked you up with one of those ass-making magazines.
-- brian d. foy as misheard by Michael G Schwern
Re: what I meant about hungarian notation
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 given. No storm intended, but I think it is sometimes right to rebutt errors in current perceived wisdom. Especially if the error has a significant effect. This is one of those times.
Re: what I meant about hungarian notation
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 hash syntax might be justified for other reasons, but not the ones given. Hm, OK. What does this access and using what method ? $foo = '1.2'; @bar[$foo]; Does it access the hash element 1.2 or the array element 1 ? Its not obvious and you cannot depend on what is in $foo, $foo = 1.2 should give identical results. and having to write @bar[$foo] or @bar[int $foo] is worse than what we have now. And solving this by saying that each variable must be declared to be hash or array does not help much as it moves the distinction from where it is useful to the reader to somewhere out of site. Having different brackets for accessing array or hash actually does help when reading code. Using the same is just adding unnecessary complexity Graham.
Re: what I meant about hungarian notation
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 move in the way you and Larry seem to.)
Having different brackets for accessing array or hash
actually does help when reading code. Using the same
is just adding unnecessary complexity
I can't tell if you mean this as a summary of your
earlier points, in which case please note response
above, or a separate point. If it is a separate point,
you don't say why, so, why?
Re: what I meant about hungarian notation
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 above is equivalent to
$bar[$foo] or $bar{$foo} in todays perl.
Having different brackets for accessing array or hash
actually does help when reading code. Using the same
is just adding unnecessary complexity
I can't tell if you mean this as a summary of your
earlier points, in which case please note response
above, or a separate point. If it is a separate point,
you don't say why, so, why?
I mean exactly what it says. Not using [] instead of {}
actually helps with readability.
Graham.
Re: what I meant about hungarian notation
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 conflating @ and %.
No it is not.
It has nothing to do with using [] instead of {}.
Yes it does. I was asking if the above is equivalent to
$bar[$foo] or $bar{$foo} in todays perl.
What is the meaning of the following four expressions in Perl6?
@bar[$foo]; # A
%bar{$foo}; # B
@bar{$foo}; # C
%bar[$foo]; # D
You seem to be advocating A and B, Me is advocating A and D.
Why is one set better than the other?
You forgot
$bar[$foo]; # $bar is an array reference
$bar{$foo}; # $bar is a hash reference
Graham.
Re: what I meant about hungarian notation
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
%bar{$foo}; # Syntax error
@bar{$foo}; # Syntax error
%bar[$foo]; # Access entry $foo of hash %bar
???
--
John Porter
Re: what I meant about hungarian notation
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 line to your program:
use Attribute::Handlers autotie = { Sorted = 'Tie::SortHash' };
Then you can write:
my %hash : Sorted;
or:
my %hash : Sorted({}, sub { $hash{$b} cmp $hash{$a}});
etc.
Damian
PS: Casey, if you'd like to make that even easier for users of your
excellent module, send me some email.
Re: what I meant about hungarian notation
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 superior to:
@bar[$foo]; # Access element int($foo) of array @bar
%bar{$foo}; # Syntax error
@bar{$foo}; # Syntax error
%bar[$foo]; # Access entry $foo of hash %bar
As I said in another mail, consider
$bar[$foo];
$bar{$foo};
Graham.
Re: what I meant about hungarian notation
@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 {}.
---
Please bear with me just a (hoefully little) longer.
Ok, why not deprecate %foo and always use @
instead and have [] and {} represent two indexing
name spaces?
In perl 6 experiments, and perl 7, you'll have % to
play with.
Re: what I meant about hungarian notation
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
Re: what I meant about hungarian notation
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 avoiding ambuguity, I said it helped
with readability when $foo held something like 1.2
But I really think this thread is going no where.
Is there REALLY a benefit in changing things to use only []
or is this change for the sake of change.
And rememeber this is still perl, so why change something unless
it gains extra benefit.
Graham.
Re: what I meant about hungarian notation
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 forget who). But beginners are not always the best people to ask. Beginner don't stay beginners for long I think the quote was. Graham.
Re: what I meant about hungarian notation
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.
Re: what I meant about hungarian notation
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
Re: what I meant about hungarian notation
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 all, even if their preferences are not to be taken too seriously.
Re: what I meant about hungarian notation
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: that depends on what $bar contains.
(Aw! That hurt!)
yeah, 'that hurt' is right. 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 disagree with unnecessary ornamentation.
So I'll take my '{}', thank you very much
Ed
Re: what I meant about hungarian notation
(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 associative.)
Re: what I meant about hungarian notation
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 stick a - between the variable and
the brace, and you have Perl 5.
@bar[$foo] in Perl 6 is @bar-[$foo] in Perl 5.
(Which, by magic, turns into what most people refer to as $bar[$foo])
%bar{$foo} in Perl 6 is %bar-{$foo} in Perl 5.
(By the same magic, this is $bar{$foo});
@bar{$foo} in Perl 6 is (almost) @bar-{$foo} in Perl 5.
Even looking at it, you can tell it makes no sense. (But Perl 5 does magic
on it anyway, so that's not the best example)
%bar[$foo] in Perl 6 is (almost) %bar-[$foo] in Perl 5.
That's similarly nonsensical, but Perl 5 is still magic.
$bar[$foo] in Perl 6 is $bar-[$foo] in Perl 5.
$bar{$foo} in Perl 6 is $bar-{$foo} in Perl 5.
--
IDIOCY:
Never Underestimate The Power Of Stupid People In Large Groups
http://www.despair.com
RE: what I meant about hungarian notation
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 disagree with unnecessary
ornamentation.
So I'll take my '{}', thank you very much
But you are assuming thre are only 2 types of indexing scheme for
collections to which $bar might be a reference. In the OO world, I can
define all sorts of wierd things, some of which may be useful. Am I forced
to write $bar.index($foo) for anything other than hashes and arrays?
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
Re: what I meant about hungarian notation
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 constrained TDI in Perl5. -- John Porter
Re: what I meant about hungarian notation
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
Re: what I meant about hungarian notation
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
RE: what I meant about hungarian notation
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
Re: what I meant about hungarian notation
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. : : Clearly the promise can be broken, so there has : to be a check somewhere along the line, right? Depends on what you count as part of the line. The check could be eliminated in many cases at compile time, when it is known that the subscript can only produce integers, and when it is known that the variable is not tied. (It is difficult to know the latter in Perl 5, but in Perl 6, lexical variables will only be tied over a lexical scope, so it is possible to know that know that no check is necessary, if the declaration does no tie.) : If there is, and the check shows you don't have a : (reasonable) integer, then perl can just switch to : a hash lookup. I'd assume you are doing : something vaguely similar to this any way, to do : sparse arrays. Sparse arrays are done currently with ties, but even sparse arrays are indexed by integer, so we could probably still use that constraint in Perl 6 as a basis for optimizing away that check, even if the particular tied array implementation deals in sparsity. : If such a check is done, and the compiler code : is written appropriately, there should be no : reason why it incurs extra machine instructions : in the event of there being an integer subscript. This assumes we're only targeting our own VM. This sort of design decision might force every integer to be represented as an object on other VMs. But that's all beside the point, in a way. I think the distinction between ordered and unordered in the mind of the programmer is more important, particularly for those of us with disordered minds. Larry
RE: what I meant about hungarian notation
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. --
Re: what I meant about hungarian notation
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 that it wasn't true when you said it. Of course, you can sit behind the definition of *they*...After all, who are they? New p6 programmers? Acolytes of Perl? ActiveState? my ORA? p5p? Hillary 33 builds of perl6 on the wall, 33 builds of perl6... --
Re: what I meant about hungarian notation
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 opportunities remained intact, do you think conflating @ and % would be a perl6 design win?
Re: what I meant about hungarian notation
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 major performance win in Perl 6. : : Assuming that optimization opportunities remained intact, They won't, but go on. : 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. 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 messages. They appear to rather like it in the UK. But then people are very weird indeed. -- Piers Cawley www.iterative-software.com
RE: what I meant about hungarian notation
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 messages. Logic error: False analogy. But as for the different operators, true, I believe, as long as we aren't introducing strong typing, or traditional typing in the $%@ sense. This addresses clarity without imposing verbosity. Add verbosity and there's no reason not to migrate to C# or Java. But then, none of this has been proposed so far except in the form of questions and concerns. p
Re: what I meant about hungarian notation
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 for containers indexed by scalar as well. -- John Porter All men are subjects.
RE: what I meant about hungarian notation
-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 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 for containers indexed by scalar as well. I don't disagree that it's a good thing, but with this piece alone aren't we falling FAAR short of that 95% mark? p
Re: what I meant about hungarian notation
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. Makes sense to have it for containers indexed by scalar as well. add an explicit accuracy limit @container : accuracy 0.01; and you've got a language where $container[2/3] is guaranteed to access the same slot as $container[.6668] Now that's what I call going up to eleven! -- David Nicol 816.235.1187 [EMAIL PROTECTED] die 'smiling' if $still_debugging;
Re: what I meant about hungarian notation
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 operators, conflated data type. That's what we have for scalars already. Makes sense to have it for containers indexed by scalar as well. add an explicit accuracy limit @container : accuracy 0.01; and you've got a language where $container[2/3] is guaranteed to access the same slot as $container[.6668] Now that's what I call going up to eleven! Suddenly, I feel like going back to C... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: what I meant about hungarian notation
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 numbers. And strings can be numbers. -- This week I will definitely have passed the Administrative Event Horizon: when you spend quite a few more hours doing silly corporate bullshite than anything remotely technical or to do with the administration of systems. - Red Drag Diva
RE: what I meant about hungarian notation
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, integers, longs, and floats are conceptually very different beasts. Shopping list, phone book. Different things. String, Integer, Long, Float. Each a different thing ^ Hash, Array, tree. Each different things ^^ Isn't the gist of the debate that if a Scalar can be any thing, surely a INSERT-NAME-HERE can be any things? Now I'm not endorsing either side, but at least I see the conflate things things like Perl conflates thing things argument. To me... Scalars, Arrays, and Hashes are just data structures for which Perl provides special syntax. Element: any thing Scalar: zero dimensional array containing one element Array: collection of elements distinguished by integer subscripts Hash:an array with element subscripts And as far as things things go, there isn't conceptual much difference between integer and element subscripted arrays. Whether or not that merits the conflation of hashes and arrays into using a common prefix or not... that's a different question. Which BTW, Larry seems to have answered for himself long ago. But did Larry etch that decision in stone or jello? Garrett
Re: what I meant about hungarian notation
: 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 than for numbers. Yes. But... I think it's rather more natural to view an array or hash element as a special form of function call than it is to view parens as operators. foo(1,2) is a function call with two numeric arguments. What syntax should one use to call a function with two string arguments? I am very happy that one does not have to use differing parens (and presumably commas) according to signature! The danger here is stretching analogies too far... Dictionaries and calculators have very different interfaces in the real world, and it's false economy to overgeneralize. From numbers versus strings as subscripts to this makes for an exquisitely ironic statement. I have lived in awe and admiration of Larry for years (and still do, I mean, A1/A2 are just incredible imo), but at last I know he's almost human!
Re: what I meant about hungarian notation
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 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. Continuing this further, why keep *any* notation at all? Why are vars with string or numeric data more worthy of $? snip We are at the point where there are so many variable types that the dollar sign on their names has become a hollow formality. Again, I'm confused. All I expect from something with a $ is that it's a single value, not necessarily a string or a number. And what if I want to treat a string-ifiable object as an untyped value? Is my var then $ worthy? - Matt
Re: what I meant about hungarian notation
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. Undecorated if for function calls and methods. And buolt-ins, of course. So what I am suggesting is, Scalar as catch-all for unclassifiables that are neither strings nor numbers may have been a historic stopgap measure in perl 5 which was seen to be unworkable given the profusion of object types which became available in perl 6. 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 run out of possible prefixes. -- Bart.
Re: what I meant about hungarian notation
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.
Re: what I meant about hungarian notation
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 aren't really scalars, but their own type. Thus they need their own prefix. No, that does not follow. -- John Porter
Re: what I meant about hungarian notation
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 need their own prefix. No, that does not follow. What he is proposing is that Perl6 would have a kind of variable that doesn't have a prefix. That isn't perlish IMO. We might just as well drop all prefixes. At least, that'd be consistent. -- Bart.
Re: what I meant about hungarian notation
[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, and | for numbers. Use $ when it's unknown what type a variable will hold, or for a variable that can hold either type. Sfoo = 'a string'; |bar = 'a number'; $baz = Sfoo || |bar; And references are right out. ;-) -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: what I meant about hungarian notation
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 perlish... :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: what I meant about hungarian notation
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 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 iterator in local scope. Of course, written more appropriately,
this would have just been static unsigned int i. 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).
Just as Python is a language that enforces the common practice of
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.
False analogy, bad example, and semantic foofoo. Python's indentation is a
burden to me. It defies flexibility and places a requirement on verbosity.
The only more annoying language I know of in terms of strict structure is
VB, which places my neat colmnar comments in irregular endings at the end of
a line (can't line anything up). Readability, to me, is the ability to MAKE
it readable, not an arbitrary rule to provide (a pretense of) readability by
forcing me to put my squiggly where I don't want it to go. As for the
Hungarian thing, Perl's $%@ is a far cry from it, though I have seen
$strSomething in new programmers.
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.
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) {
$i.asFloat += 0.1;
}
$i.asString .= Foo, Inc.;
We appear to be moving in that direction, trading programmer convenience
with politically correct verbosity.
my dog $spot; #spot is a dog that looks like a scalar
#spot holds neither numeric nor string data
#why is spot burdened with the BASIC
#string identifier?
$ isn't BASIC. (Actually, ancient BASIC was var$ rather than $var.) It's a
remnant from other UNIX utilities such that
set this = that;
print $this;
% and @ also have historical context that makes sense.
So what I am suggesting is, Scalar as catch-all for unclassifiables
that are neither strings nor numbers may have been a historic stopgap
measure in perl 5 which was seen to be unworkable given the profusion of
object types which became available in perl 6.
As long as it roughly resembles the Perl language.
RE: what I meant about hungarian notation
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 in a traditional sense. Organization - type is semantic oddery, but they do keep our heds straight about what's in the variable. 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. Continuing this further, why keep *any* notation at all? Why are vars with string or numeric data more worthy of $? What do you suggest? m_sc_I? (An object member variable that's a scalar named I.) Bah! snip We are at the point where there are so many variable types that the dollar sign on their names has become a hollow formality. Again, I'm confused. All I expect from something with a $ is that it's a single value, not necessarily a string or a number. And what if I want to treat a string-ifiable object as an untyped value? Is my var then $ worthy? If all types are references, $ does appear to lose some of its historical distinction. On the other hand, @foo[1] as a replacement for $foo-[1] does have some linguistic merit, so I've been listening to it with interest. My primary concern in this area is the introduction of forced verbosity. p
Re: what I meant about hungarian notation
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.
There are two very important reasons why $%@ is more than just YA
Hungarian Notation. I believe Abigail pointed this out to me some
time ago.
The first, string interpolation. $ lets Perl be fairly unique in
having a simple way to interpolate variables in strings. Its a fairly
clear distinction between a bare word and a variable.
With the idea of interpolating method calls in strings on the table,
it now becomes rather important to have that $ on objects.
print The $animal.name says: $animal.sound\n;
Of course, we could disambiguate by requiring the () as class methods
will...
print The animal.name() says: animal.sound()\n;
But that leads to the second Very Important Reason. Distinguishing
between object method and class methods. In the above example, it is
not clear if you're calling the method 'name' on the class 'animal' or
on the object 'animal'.
The inevitable clash will happen where a variable name will match that
of a class name and no simple rule can solve it. Object methods
cannot have precedence over class methods else there becomes no way no
call that class method.
I'm sure some set of special, optional disambiguating syntax (similar
to ${var}) could be dragged in, but it seems like you're just trading
one bit of inconsistency for another.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
If you have to shoot, shoot! Don't talk.
-- Tuco, The Good, The Bad And The Ugly
Re: what I meant about hungarian notation
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 arrays and hashes. -- John Porter
Re: what I meant about hungarian notation
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). Not mention the hoop-jumping required to keep variable names in sync with code changes. (signed-ness, short-int-long, etc) Which reminds me... One of the fundamental functions in the Windows API is SendMessage. Here, one can give two parameters. They're call wParam and lParam. Yes, originally, wParam was a word (16 bit), and lParam was a long (32 bit). But under the Win32 API, every kind of integer was turned into a long, but the names wParam and lParam still stuck, despite the fact that both are now 32 bit integers. -- Bart.
Re: what I meant about hungarian notation
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 different. -- About the use of language: it is impossible to sharpen a pencil with a blunt ax. It is equally vain to try to do it with ten blunt axes instead. -- Edsger Dijkstra
Re: what I meant about hungarian notation
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 notation. Otherwise (as has already been noted), we'd need line noise for each data type. This is the crisis that David N sees... I'm questioning whether there is such a crisis. Continuing this further, why keep *any* notation at all? Why are vars with string or numeric data more worthy of $? What do you suggest? m_sc_I? (An object member variable that's a scalar named I.) Bah! Actually, you can do that now. I've seen $m_I. Of course, that was from a C++ guy that was just learning Perl. I abhor Hungarian notation. It's the dark side of Lazy. And chances are that if you actually *need* it, your code needs some serious factoring, IMHO. My primary concern in this area is the introduction of forced verbosity. Typing is good for you. It builds strong bodies 8 ways. - Matt
RE: what I meant about hungarian notation
-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
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
arrays and hashes.
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']
or something similar in Perl 6. Heretofore the issue may have been the
indexing done by hashes, but since these will become actual objects in Perl
6, *how* they are indexed could be a simple flag (sorted | numeric, sorted |
string, fast | string, etc.)
The result would be two types of variables: single and multiple.
But I imagine that this has been gone over many times.
p
Re: what I meant about hungarian notation
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 say
my foo;
to mean the above, or something like it. So people who hate funny
characters can define as many bare names as they like. They'll just
have to figure out how to interpolate them, and they'll have to use
explicit method calls to establish some of the context that Perl can
currently guess from the funny characters. And they'll likely be
reviled by the people who prefer the culture of $ and @. There may be
wars fought, and the standard Perl libraries may be subject to ethnic
cleansing. Culture wars arise spontaneously, but that should not deter
us from enabling people to build new cultures. Perhaps some of those
new cultures will be slightly less hostile to other cultures, knowing
their multicultural roots. If Perl culture has no other effect on the
world, I hope it shows how a culture can be aware of both its own
strengths and its own limitations.
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
Re: what I meant about hungarian notation
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
sub AUTOLOAD : lvalue { $$AUTOLOAD }
Didn't finish it, but got close enough.
--
Britain has football hooligans, Germany has neo-Nazis, and France has farmers.
-The Times
Re: what I meant about hungarian notation
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'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.
Larry
RE: what I meant about hungarian notation
[...] 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
Re: what I meant about hungarian notation
Simon Cozens wrote: A scalar's a thing. Just as the index into a multiplicity is a thing. -- John Porter
Re: what I meant about hungarian notation
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 result would be two types of variables: single and multiple. Ah! :-) -- John Porter
Re: what I meant about hungarian notation
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.
Re: what I meant about hungarian notation
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, you oughta teach this stuff. :) -- Jenkinson's Law: It won't work.
Re: what I meant about hungarian notation
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) {
$i.asFloat += 0.1;
}
$i.asString .= Foo, Inc.;
We appear to be moving in that direction, trading programmer convenience
with politically correct verbosity.
that isn't what I suggested.
With references-in-scalars, the p5 status quo, there's no hint at all what
$R refers to. It might not be a reference, but it might be a genuine
scalar, holidng a number or some text. You can't deny this is a confusing
state of affairs. I have no idea if
print $R
is going to give me a reasonable output or some internals-debugging noise.
We even have the Cref operator to help us with this problem
sub deref($);
sub deref($){ref $_[0] ? deref $$_[0] : $_[0]);
print deref $R;
So why not, since the $ preceding the name of a reference doesn't do
a whole lot, let's deprecate it?
1 @$R
2 @{$R}
3 @{R}
4 @{R}
5 @{'R'}
6 @R
How much difference does it make, in situations where these
are all defined, 6/3 starts binding to 4 rather than 5?
You know, we have it (undecorated variablkes) already, if we don't mind
always using
curlies around variable names, we can create subroutines to return
references for
each and every variable.
my Dog spot;
could, in p5 terms, be short for something like this:
{
my $obj = new Dog;
sub spot { return $obj }
};
This is the exact same discussion from October 2000. :)
Re: what I meant about hungarian notation
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 itself echoes the notsbolts availability of memory addresses as integer types. Which cause[s|d] so much confusion when porting 32-bit code to 64-bit architecture If perl6 variable decorations switch from Part-Of-The-Name to type casts, pretending that a reference is a string continues to make the same amount of sense as pretending that a pointer to a structure is an integer. It works, but it's troublesome. -- David Nicol 816.235.1187 [EMAIL PROTECTED] all your base are belong to us, Will Robinson
Re: what I meant about hungarian notation
push chairs, map {woodworking} treestumps;
or even
push chairs, map BLOCK(woodworking) treestumps;
