Michael G Schwern wrote:
> I'm going to say you need sigils for this:
>
> print "Hello, my name is $name\n";
>
> You're going to say this:
>
> print "Hello, my name is $(name)\n";
I actually prefer
print "Hello, my name is ",name,"\n";
or,
the sigil is simply optional, and "hello my name is $name"
still works.
but that's neither here nor there. Guido apparently finds all
variance from printf formatting confusing and unweildy. I said
the horse was dead when I rode in on him.
> The real problem isn't [sig digs]. The real problem is how much this
> complicates the implicit typing rules. I'm going to have to play
> around a bit and see which way works best.
I hope you're proposing that fatal errors on poor conversion is
off by default.
> > > You'd have to do an explicit typecast (syntax left as an exercise).
> > > Given that most times when you try to use a reference as a string
> > > you're making a mistake, this shouldn't be a big deal.
> >
> > This would be a nice thing to have a pragmata for, what hash refs
> > stringify to.
>
> Why? Example of use?
I had a situation where I cared if refs were reffing the same object or not
and interpolating them was actually handy. But there are other situations
where it might be nice to have them expand to their keys, expand to their
values, or expand to their perl5 arrayifications. So why not support all
of them and defer the decision to the user. When in doubt, do everything.
> > > Now, here's an example of something that might be really annoying to
> > > get right. Let's say localtime() returns a hash in Perl 6 (sensible).
> <snip>
> > localtime would return a magic read-only hash reference.
> <snip>
>
> I just picked localtime() as a sufficiently complicated example. I
> don't really want to discuss its interface here. See sigils above.
Oh. I thought you were asking, would the interface would have to be fully
described for the assignment to occur, and I said no, I don't think it
would have to be.
> The real question: variables implying their types from function
> signatures... is it sane?
it's backwards. Everyone else (C++, the polymorphic dispatch RFC)
selects the function based on the signature required to satisfy the
constraints of the required return type, and you want to imply the
return type based on the function signature.
It (variables implying their types from function signatures) could
co-exist with multiple dispatches, for functions that only have one
possible return type. And with a function that returns a well-defined
packed structure with associated accessor methods, keeping that structure
at an offset into a block scratchpad (instead of an array-of-references
scratchpad) might be a cool optimization.
You would give up dynamic function overloading, and a passle of other
rarely
used features you could look for and call off the optimizations if you
see, or keep the parse around to rebuild the executable when the
definitions
are no longer current. At overload time, the code at the old address for
the newly redefined routine is changed to cause the enclosing block to
get rebuilt, that would be better than checking all the time. Every routine
that is inlinable would need to maintain a list of where it was inlined,
for this eventuality. --no-inlines could be one of those compiler
promises.
This crap is all probably patentable -- at times like this I'm glad I
fucked up the IBM job interview in August, 1986 -- My brain! Mine!
So, yeah, sure -- variable type implied from return type. There are
some rocks around, so don't surf near them.
> > > my $foo; # *error* forgot to declare a type.
> > >
> > > We could have Perl go through heroics to try and find $foo's first
> > > assignment and imply a type from that, but I think that will rapidly
> > > get Messy and Surprising.
> >
> > my $foo; # PMAW
>
> PMAW?
Perl's Magical Autoconverting Wondervariable. I introduced the
abbreviation
earlier in the post, while you were busy having a blind rage about me
resurrecting my scheme to deprecate the scalar sigil.
The "draw of the PMAW" is why we're all here (rather than outside
in the heat, tinkering with our regenerative braking systems) in
the first place.
--
David Nicol 816.235.1187
"Perl was born in downtown Hell!" -- Matt Youell
