Re: Allomopherencing
On Mon, Sep 26, 2005 at 17:36:04 -0700, Larry Wall wrote: > Sure, when it slows down your compiler so much that it's useless for > running code that doesn't have the error, especially if it's a rare > error that is likely to be caught some other way anyway. Where to > balance this should be the decision of the user, particularly since > the balance point changes over time and space. Good point... Is there half-way solution, btw? Perhaps type inferrencing annotation rich areas is a good idea to help a user who is trying to debug by adding more of these. > It's also potentially counterproductive if the information available > at compile time leads to confusingly abstract error messages when > run-time information might produced clearer concrete error messages. > When I use the term "confusing", I do so in the Pooh sense. I'm trying > to think of what will be confusing to ordinary folks, not to geniuses > like you. *blush*. For the record it takes me roughly 1 irc client or around 10 careful, concentrated rereadings to understand what GHC tells me in these situations, but for the record. A useful reference is the Error Messages section on this page: http://www.haskell.org/ghc/survey2005-summary.html It mentions both that there are active areas of research on how to make these better, and that GHC messages both suck and don't suck at the same time. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me dodges cabbages like macalypse log N: neeyah! pgpb2QyvQWJkC.pgp Description: PGP signature
Re: Allomopherencing
On Sun, Sep 25, 2005 at 08:29:07PM +0300, Yuval Kogman wrote: : Is there any situation where a compile time error is not a good : thing to have? Sure, when it slows down your compiler so much that it's useless for running code that doesn't have the error, especially if it's a rare error that is likely to be caught some other way anyway. Where to balance this should be the decision of the user, particularly since the balance point changes over time and space. It's also potentially counterproductive if the information available at compile time leads to confusingly abstract error messages when run-time information might produced clearer concrete error messages. When I use the term "confusing", I do so in the Pooh sense. I'm trying to think of what will be confusing to ordinary folks, not to geniuses like you. I'd love to be proven wrong, but I strongly suspect that most type-inferencing error messages will be complete gibberish to commonfolk. Larry
Re: Allomopherencing
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote: > > In order to enforce that level of compile-time type safely, you should > > need to declare my Dog $dog, or stick a pragma up top: > > That's the point of my question - why? What do I lose by > inferrencing? Nothing that I see. I recant my arguments when strict inferencing is in place. That's exactly how I'd want it to work when optimization and/or stricture is in place. It'd be a *very* nice compiler feature. Ashley Winters
Re: Allomopherencing
On Sun, Sep 25, 2005 at 11:24:05 -0700, Ashley Winters wrote:
> I can't accept that. While you can infer that $dog will be a Dog at
> that line of code, it isn't being enforced, which means no
> compile-time error. $dog is allowed to store any kind of data, and you
> only know what methods exist in Dog at compile-time. After all, I was
> planning to add a &Dog::as(Cat) method at runtime. Yes, I'm a mad
> scientist. Muahahaha!!!
If you say
my $pet = Dog.new;
if ($condition) {
$pet = Cat.new;
}
my Car $spot = $pet;
Then $pet's type is inferred to Cat|Dog, and must be able to contain
either of those, but that is still not a Car.
I'm assuming under use optimize where everything is closed.;
> In order to enforce that level of compile-time type safely, you should
> need to declare my Dog $dog, or stick a pragma up top:
That's the point of my question - why? What do I lose by
inferrencing?
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me climbs a brick wall with his fingers: neeyah!
pgpEkBSPIsL67.pgp
Description: PGP signature
Re: Allomopherencing
On 9/25/05, Ashley Winters <[EMAIL PROTECTED]> wrote: > On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote: > > Under strict type inferrencing, i'd expect this to be a compile time > > error: I quoted but didn't read close enough. You DID say strict type inferencing. Never mind. :) Ashley Winters
Re: Allomopherencing
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> Hmm... Making up these subjects is fun =)
Very interesting. :)
> Under strict type inferrencing, i'd expect this to be a compile time
> error:
>
> my $dog = Dog.new;
>
> if ($condition) {
> my Cat $c = $dog;
> } else {
> ...
> }
>
> since it's guaranteed to be a runtime error if $condition is ever
> true.
I can't accept that. While you can infer that $dog will be a Dog at
that line of code, it isn't being enforced, which means no
compile-time error. $dog is allowed to store any kind of data, and you
only know what methods exist in Dog at compile-time. After all, I was
planning to add a &Dog::as(Cat) method at runtime. Yes, I'm a mad
scientist. Muahahaha!!!
In order to enforce that level of compile-time type safely, you should
need to declare my Dog $dog, or stick a pragma up top: use sadistic
; either of those declarations can disregard my potential
for runtime tomfoolery, and abort the compiliation when there's
something illogical.
Ashley Winters
Allomopherencing
Hmm... Making up these subjects is fun =)
Anywho...
Since type inferrencing is going to make into Perl 6, and
allomorphism is very richly supported by the type system, i'm
wondering on the nature of the optionality...
What excatly do the users get to control? Are functions with '-->'
rich type signatures going to limit the user in any way? What should
the functions in the prelude be defined as?
Under strict type inferrencing, i'd expect this to be a compile time
error:
my $dog = Dog.new;
if ($condition) {
my Cat $c = $dog;
} else {
...
}
since it's guaranteed to be a runtime error if $condition is ever
true.
Is there any situation where a compile time error is not a good
thing to have?
If allomorphism is enough such that the class that implements the
actual integers, which does Str, Int, Num, Ord and all that for the
yummy operations we can do on it, and expressions like
"foo" ~ 42 ~ "Bar"
are type safe, is there really any reason to ever not give compile
time errors to type errors?
Also, is it rational to say, within a lexical pragma, that such
zealous allomorphism is prohibited, in order to get more rigid type
semantics for that block? If so, how is this defined?
On the other side of the spectrum, is there any situation where type
safety is ever a bad thing, if it's inferred, and flexible?
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!!
pgpPThiBbNSi3.pgp
Description: PGP signature
