Re: Feeding potatoes to dead horses

[Michael G Schwern]

On Thu, Jul 12, 2001 at 06:56:25PM -0700, Dave Storrs wrote:
 On Tue, 10 Jul 2001, Michael G Schwern wrote:
  You can always just do this:
  
  my Value $foo;
  
  And $foo will act like a normal scalar taking anything (your PMAW).
 
   If that's the goal, I'd vote that it be spelled:
 
 my Scalar $foo; 

Yeah, I'm just a little worried it will be confused with

my SCALAR $scalar_ref;

but it should be fine.

-- 

Michael G. Schwern   [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED]   Kwalitee Is Job One
ck and shiny crust
over my hairy anus
constipation sucks
-- Ken Flagg

Re: Feeding potatoes to dead horses

[Dave Storrs]

On Tue, 10 Jul 2001, Michael G Schwern wrote:

 We could assume untyped variables are untyped, but I'd rather they're
 considered mistakes.  Again, the purpose here is to catch mistakes.  I
 don't know if this will wind up being more or less annoying, we'll
 have to play with it a little.  Fortunately, its a decision that can
 easily be reversed.
 
 You can always just do this:
 
 my Value $foo;
 
 And $foo will act like a normal scalar taking anything (your PMAW).

If that's the goal, I'd vote that it be spelled:

  my Scalar $foo; 

--Dave

Re: Feeding potatoes to dead horses

[Michael G Schwern]

On Tue, Jul 10, 2001 at 01:02:18AM -0500, David L. Nicol wrote:
  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 mean if you try this:

my Num $foo = 4.2;
my Int $bar = $foo; # *error*  loss of information

that would be fatal, yes.  I think that's the right thing to do, its
exactly the sort of thing types are made to defend against.  You can
always cast:

my Int $bar = int($foo);


PS  This is *ALL* off by default.


   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.

This appears to be outside the scope of this discussion.  Refs don't
do any of that right now with or without typing.

If you're building strong typing, some magic has to go.  99% of the
time when you use a reference as a string its a mistake.  Ergo,
references do not automatically cast.  You can always make an explicit
cast or bless your refs and overload their references'
stringification.

Remember, the idea here is to catch mistakes.


 When in doubt, do everything.

Unfortunately, there's a very finite amount of tuits available to
implement all this, not to forget document, test and teach.

When in doubt, stop and rethink.


 my $foo;# PMAW
  
  PMAW?
 
 Perl's Magical Autoconverting Wondervariable.
 
 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.

We could assume untyped variables are untyped, but I'd rather they're
considered mistakes.  Again, the purpose here is to catch mistakes.  I
don't know if this will wind up being more or less annoying, we'll
have to play with it a little.  Fortunately, its a decision that can
easily be reversed.

You can always just do this:

my Value $foo;

And $foo will act like a normal scalar taking anything (your PMAW).


Rather than just speculate, I'm going to go play with this idea for a
while.


-- 

Michael G. Schwern   [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED]   Kwalitee Is Job One
I was *meant* to mount your donuts.

Feeding potatoes to dead horses

[David L. Nicol]

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