On Wed, Mar 26, 2003 at 09:49:38AM +0100, Kay Roepke wrote:
>
> On Wednesday, March 26, 2003, at 04:29 AM, Adam Turoff wrote:
>
> >I've never come across a programmer who wishes he could do this
> >in C and have the compiler magically know what's what:
> >
> > int spam (int spam, char **spam) {
> > int eggs;
> > double spam;
> > return 0;
> > }
>
> It's very obvious that the C programmer can't distinguish between spam
> and spam (no pun intended :-)).
> That's the whole point of sigils!
>
> Well, in Perl you don't use it like that, anyway. If you mean the
> scalar variant (portion)
> if data you write $data. If you mean the array you write @data. (Note
> that in Perl6 the notion
> of using the $ sigil when accessing the elements (as in $data[0]) is
> gone.)
>
> IMHO the visuals are pretty clear and state the type of a variable not
> only at place it's been declared, but
> rather all over the program. I really like that reminder when reviewing
> code (esp. when it's +10_000 lines ;-))
Yes. The existence of sigil is a feature that gets even more consistent
with Perl6. It does not goes overboard like the naming Microsoft
convention that use type to suffix name variables:
http://www.shadowmud.org/Documents/Naming.htm (I forgot the name of
the guy who pionnereed it) but it does not precludes it either.
Sigils follow the convention that important things should come first.
They say me what I can do with the "sigiled" variables. It is also a
form of HuffMan coding, type indication happenning often (because of
the deliberate choice of indicating at each reference and not only at
declaration), it had to be short.
But should be allowed to declare in the same scope @a, %a and $a?
Definitively yes because it permits to use the same sigless name for
related variables:
In Perl5:
# it is very natural for me that iterator has the
# same siless name than the object iterated upon.
for my $a (@a) {
...
}
# here %a, and @a have also a close relationship.
my (%a, @a);
$a{$_++} for @a;
The major gripe I have with Perl6 is that space is not used as syntax
when meaningful and not as mere token separator, generally optionnal;
I will restrain here myself to talk about it in the restricted context
of the (overuse) of sigils.
In font design, non alphabetic characters are not intended to be
concatenated with other characters like alphabetic characters are to
make a natural visual flow. BTW: Serifs are designed to help this flow but
it works only on high-resolution devices.
Non alphabetic characters are very conspicuous, so redundancy should
be avoided. But Sigil _and_square/curly bracket are redundant.
Space as syntax can be a device to drop the sigil when dereferncing an
array or a hash.
a [$a] # call the function a with a reference to an array as parameter
a[$a] # dereference the array @a
Same thing goes for C<a {$a}> and C<a{$a}>.
Certainly, within double quotes one has to write C<@a[$a]> because
without the sigil, that would be to easy to accidentally dereference
an array. This is a case of preferring convenience over
consistency. Probably for the consistency freaks C<a[$a]> should be
allowed as well as C<@a[$a]> outside double quoting context.
--
stef
>
>
> Kay
>
