Nathan Wiger wrote:
>
> "David L. Nicol" wrote:
> >
> > They gain us compliance with the whims of the people who like barewords
> > for variable names. You may or may not find that to be a good thing.
>
> It's not just that I don't think dropping $'s is a good idea, but that
> is the general consensus as well. I can't see
>
> dog spot;
>
> Ever getting into Perl realistically. For one thing, that already has
> strong meaning as:
>
> spot->dog;
>
> Because of the truly wonderful indirect object syntax.
No, that would be
dog $spot;
unless I am misunderstanding what
spot->dog; # is supposed to mean to you.
###########################################
typedef struct{
char name[40];
char breed[50];
dog_info_t info;
}dog; # a dog is a type of ( 90 + sizeof(dog_info_t) )bytes
my dog $spot; # something like $spot = dog::new;
# $spot represents a *SV somewhere not
# directly tied to program flow
dog malt; # malt is sizeof(dog) bytes reserved in the
# "stack frame" of the current subroutine call,
Having the C types line up with the Perl packages is not automatic, or
we could have C types all scalarize to strings holding themselves, for
access into using "pack" and "unpack" as well as direct accesses using
hash syntax
strcpy(malt.name, "malt"); # this is a perl5 syntax error
# so perl6 could fall back to interpreting
# the expression as C before throwing
# a syntax error exception
%malt{name} = 'malt'; # clearly this is perl
barewords with and without scalar symbol -- the $ is a scalar symbol --
mean as different of things as %malt and $malt do in perl5
You can have your general consensus, I'm not in his army.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Kansas City Perl Mongers will meet Sept. 20th at 7:00 in
Westport Flea Market Bar & Grill http://tipjar.com/kcpm
