Re: Type annotations
HaloO, I fear I'm addicted... Luke Palmer wrote: On 10/7/05, chromatic [EMAIL PROTECTED] wrote: On Fri, 2005-10-07 at 17:43 -0600, Luke Palmer wrote: No, you can't overload assignment at runtime because you can't overload assigment at any time, so says the language spec (well, not any formal spec; so says Larry as far as I remember). Again, I don't care *how* I accomplish it, as long as I don't have to root around in the source code of Perl 6 itself to make it work. That's easy. Define coerce:as (Int -- Array) {...}. Don't define it after CHECK is run. But that makes MMD at most a second class concept. Worse is that this hinders the concrete formulation of abstract concepts into which designers can hook their stuff. Assignment to me is a non-commutative, or if you like that better, asymmetric binary operator. The asymmetry beeing that the LHS takes the burden to keep the connection to the value of the RHS at that time. I call the thing that Larry wants to preserve a slot call. That is $x = $y; actually means $x.STORE( $y.FETCH ); where I would write the .STORE and .FETCH methods with adverbial pair syntax :STORE and :FETCH because they are looked up from the things that $x and $y contain or refer to at runtime while the dot forms are dispatched on the type. In other words the generated code is different in both cases. But usually the net result is the same because the .STORE method has the same targets for the usual types of $x as the vtbls that different types of $x carry around. BUT you can break that symmetry *either* by changing the entries in the method *or* some vtbls! And if you want to base your decision which route to take on *both* the participants you write a *multi* method for infix:{'='}. And only if none of the above is satisfactory messing with the parser/grammar should be considered. I have the impression that Perl 6 pulls out this rather heavy-weight tool too early in many cases. -- $TSa.greeting := HaloO; # mind the echo!
Re: Type annotations
The more I think about it, the more I'm convinced that perl6 (by default) shouldn't refuse to run programs because of a (perceived or real) type error. It should, of course, emit a compile-type type *warning*, which can be silenced or made fatal at the user's discretion. There are a few reasons behind this: 1) If I'm not using type annotations in my code, I shouldn't be forced to go out of my way to satisfy the typechecker before my program will even run, just because I used external subs that have (incompatible) type annotations. Of course, my program will fail at run-time when the predicted type error actually occurs, but in this case we're no worse off than in any other dynamically-typed language--and at least I had advance warning from the compiler. 2) Even if a program has a compile-time type error, it may be possible to use part of the program's functionality without ever encountering a run-time type error. If a program has two modes, A and B, and the type errors are all in the code for B, it makes no sense to prevent the program from running in mode A. If I'm trying to fix run-time bugs in A, I shouldn't have to repair B before I can even start. 3) perl6 should be quite capable of running an ill-typed program, right up until the point at which a run-time type error actually occurs. Perl 6 isn't one of those languages that needs code to be well-typed in order for the compiler/runtime to figure out how to actually execute it. (Well-typedness helps for optimisation, of course, but it isn't *required*.) Stuart
Re: Type annotations
Yuval Kogman skribis 2005-10-07 3:02 (+0200): my Array $a = 97; # dies eventually, but when? my Int $b = 3.1415; # dies at all? Both die at compile time, because the user explicitly contradicted him/herself. This is like saying my int = $x :: float; For my Int $c = $float, though, I'd want coercion. And I think it is wrong to have such a huge difference between literals and values: if a variable coerces, a literal has to do so too. I believe that any value should be hardcodeable at any time, for testing and debugging new code. Hard coding a value temporarily shouldn't suddenly make the program die. Otherwise we'll end up with more of the dreaded my $dummy = ... since they're constants and their types are very well known. What is the type of 1.0? I'd prefer all literal numbers to be Num and never Int (this doesn't mean that this specific case can't be optimized to an Int). Likewise, all literal strings should be Str, and all literal arrays should be Array, and all literal hashes should be Hash. (Ignore for a moment that the latter two are references.) The keyword here is all :) sub foo (Int $arg) {...} foo(hello); # should die at the latest when foo() is called There are two reasons to make this die, and I agree with only one of them. (a) Die because the argument passed is Str (b) Die because hello can't in a useful way be coerced to a number If it dies because of b, very good. If because of a, I think we have a huge difference of opinion regarding automatic coercion. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Type annotations
Ashley Winters skribis 2005-10-06 19:30 (-0700): my Array $a = 97; # dies eventually, but when? Runtime -- cannot coerce Int value to Array It is fully determinable at compile time. 97 will never be compatible with Array, so I see no reason to wait. Do remember that some programs run for weeks or months, rather than a few seconds. It's nice to get all the certain failures during compile time. sub foo (Int $arg) {...} foo(hello); # should die at the latest when foo() is called $arg should be undef but Exception::InvalidInteger(Str value 'hello' cannot be coerced to an Int at $?LINE) That'd be a problem with sub foo (Int $arg //= 5) { ... } because the hello is then silently ignored eventually. But, these unthrown exceptions should be emitted as warnings anyway, so it is not really a problem, because everyone has warnings enabled all the time. I wouldn't mind this to fail. If it fails, it can die or be undef, depending on the user's wishes. In my case: die. If bar returns a Str ~~ /Perl6::Grammar::Int/, it gets coerced; otherwise, undef but Exception hello 5 worlds? /^.../ perhaps? And I think we should match against Num, not Int, as it's very hard to have a rule that matches just integers. 0.5e3 is an integer, but 0.5e-3 is not. As stated in my previous message, I think that all numbers should be parsed the same way, and interpreted as Nums. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Type annotations
On Fri, Oct 07, 2005 at 12:42:01 +0200, Juerd wrote: For my Int $c = $float, though, I'd want coercion. And I think it is wrong to have such a huge difference between literals and values: if a variable coerces, a literal has to do so too. How do you tell the compiler this must never be a float, ever? There is a conflict between the usefulness of coercion and the usefulness of staticness, and I think we need to be able to express both. Perhaps we need two ways to type annotate: hard annotations - applies to assignment or binding lvalues, and states that the type must be an accurate subtype - no coercion is allowed at all. soft annotations - applies to assignment or binding lvalues, and specifies that the thing contained in it must always be of the annotated type, after the assignment. That is - a value must be coerced as a copy to enter this container if it's type doesn't match. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me sushi-spin-kicks : neeyah pgpT5DKCUCMHu.pgp Description: PGP signature
Re: Type annotations
Yuval Kogman skribis 2005-10-07 12:53 (+0200): On Fri, Oct 07, 2005 at 12:42:01 +0200, Juerd wrote: For my Int $c = $float, though, I'd want coercion. And I think it is wrong to have such a huge difference between literals and values: if a variable coerces, a literal has to do so too. How do you tell the compiler this must never be a float, ever? By cramming it into a variable that cannot hold a float. I think there should be some syntax to disable coercion, but that coercion must be the default behavior. A simple operator that can be placed flexibily would certainly help. I'll demonstrate with (!), although that's probably not the right glyph: sub foo (Int $foo); # coerce, possibly lossily sub foo (Int(!) $foo); # coerce, but only if possible without loss my Int(!) $foo = $bar; my Int $foo = (!)$bar; sub bar (Int $foo); bar((!)$float); Unintentionally, the (!) is always left of the sigil. I like that, even though whitespace-wise I see it as two different things. Maybe the default should be configurable, allowing lossy coercion being the default default, and (?) can be used to override a current default of disallowing lossy coercion. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Type annotations
On Fri, 2005-10-07 at 12:49 +0200, Juerd wrote: Ashley Winters skribis 2005-10-06 19:30 (-0700): my Array $a = 97; # dies eventually, but when? Runtime -- cannot coerce Int value to Array It is fully determinable at compile time. 97 will never be compatible with Array, so I see no reason to wait. If I added a multisub for Array assignment so that assigning an integer value set the length of the array, would 97 be compatible with Array? Do remember that some programs run for weeks or months, rather than a few seconds. It's nice to get all the certain failures during compile time. How about in unreachable code (which I do actually believe compilers can detect some of the time)? -- c
Re: Type annotations
chromatic skribis 2005-10-07 12:50 (-0700): my Array $a = 97; # dies eventually, but when? Runtime -- cannot coerce Int value to Array It is fully determinable at compile time. 97 will never be compatible with Array, so I see no reason to wait. If I added a multisub for Array assignment so that assigning an integer value set the length of the array, would 97 be compatible with Array? If that is actually possible: good point. Do remember that some programs run for weeks or months, rather than a few seconds. It's nice to get all the certain failures during compile time. How about in unreachable code (which I do actually believe compilers can detect some of the time)? I'm quite ambivalent about this. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Type annotations
On 10/7/05, chromatic [EMAIL PROTECTED] wrote:\ If I added a multisub for Array assignment so that assigning an integer value set the length of the array, would 97 be compatible with Array? You're not allowed to overload assignment. But you are allowed to overload coersion. Essentially, every expression gets a coerce:as($expr, $current_context) wrapped around it (where these are optimized away when they do nothing). If you allow definition of these at runtime, there are two side-effects: 1) No typechecking can ever take place in any form. 2) No coerce calls can ever be optimized away. These are very unfortunate. So I'm inclined to say that you can't overload coersion at runtime. Juerd writes: Do remember that some programs run for weeks or months, rather than a few seconds. It's nice to get all the certain failures during compile time. There is a tradeoff around typecheckers that bounce on either side of the Halting program. Either: There are programs you call erroneous when they are not; or there are programs you call correct when they are erroneous. I get the impression that most of us want the latter kind for annotations (in the absence of use static). Luke Luke
Re: Type annotations
On Fri, 2005-10-07 at 15:22 -0600, Luke Palmer wrote: On 10/7/05, chromatic [EMAIL PROTECTED] wrote:\ If I added a multisub for Array assignment so that assigning an integer value set the length of the array, would 97 be compatible with Array? You're not allowed to overload assignment. $ perldoc perltie I don't really care how I do it, provided that I don't have to write PIR or C just to make this possible, but I want the option to have at least same power as Perl 5 to do weird things if that's what it takes to do really useful things that you or I or @Larry can't imagine right now. But you are allowed to overload coersion. Essentially, every expression gets a coerce:as($expr, $current_context) wrapped around it (where these are optimized away when they do nothing). If you allow definition of these at runtime, there are two side-effects: 1) No typechecking can ever take place in any form. 2) No coerce calls can ever be optimized away. These are very unfortunate. So I'm inclined to say that you can't overload coersion at runtime. No one can ever overload assignment or coercion at run time because you want theoretical programs you haven't yet to run VERY VERY FAST? Me, I just want to get my job done without always having to ponder the beauty of type conceptual purity while I'm fiddling with BEGIN blocks and CHECK blocks and INIT blocks, trying to dodge inscrutable type mismatch errors while guessing the combination of the locks on the escape hatches built into the language. I'm sort of feeling the inclination to argue for a lexical RUN VERY VERY FAST switch that lets you (or me sometimes) the programmer say Go on and hurt me when it's totally worth it, not to apply cheese graters, hot peppers, and David Hasselhoff CDs with fulsome BD glee to every programmer who ever types perl6 ./hello_world.pl. -- c
Re: Type annotations
On 10/7/05, chromatic [EMAIL PROTECTED] wrote: On Fri, 2005-10-07 at 15:22 -0600, Luke Palmer wrote: But you are allowed to overload coersion. Essentially, every expression gets a coerce:as($expr, $current_context) wrapped around it (where these are optimized away when they do nothing). If you allow definition of these at runtime, there are two side-effects: 1) No typechecking can ever take place in any form. 2) No coerce calls can ever be optimized away. These are very unfortunate. So I'm inclined to say that you can't overload coersion at runtime. No one can ever overload assignment or coercion at run time because you want theoretical programs you haven't yet to run VERY VERY FAST? No, you can't overload assignment at runtime because you can't overload assigment at any time, so says the language spec (well, not any formal spec; so says Larry as far as I remember). I gathered that the reason for this was not for speed, but for semantic consistency, like in Perl 5. My perspective on the argument is that if you let people overload assignment, then you make everyone uneasy about assigning for fear that it will be dwimmifully overloaded and not do the right thing. But I'm just taking that part from what I know. Also, only the second of my two reasons had to do with speed, which I agree can't be argued until we see some numbers (but I have a hunch, because not optimizing away the _many_ do-nothing coersions, you are effictively adding a complex trace condition in a debugger; and you have seen how slowly those run). As for the first argument, presumably people put type annotations on their code so that we can do some reasoning and tell them about errors. If type annotations didn't do that for my code, I wouldn't use type annotations (in fact, I probably won't end up using them too much anyway). But by allowing the definition of new coersions at runtime, you invalidate any error a type checker might think it has found. Not to say that a lexical pragma saying keep all coersions in the generated code so that if you expect to be doing something nasty in a scope, you can. But again, you kill any typechecking that code might be wanting, and you probably reduce the code's speed by an order of magnitude (again, just a guess). Luke
Re: Type annotations
On 10/7/05, Luke Palmer [EMAIL PROTECTED] wrote: On 10/7/05, chromatic [EMAIL PROTECTED] wrote: On Fri, 2005-10-07 at 15:22 -0600, Luke Palmer wrote: But you are allowed to overload coersion. Essentially, every expression gets a coerce:as($expr, $current_context) wrapped around it (where these are optimized away when they do nothing). If you allow definition of these at runtime, there are two side-effects: 1) No typechecking can ever take place in any form. I'd like to add that most people don't want typechecking if you don't insert annotations, so you're not subject to type purity there. I was arguing for making the annotations that people do willfully put in actually mean something. Luke
Re: Type annotations
On Fri, 2005-10-07 at 17:43 -0600, Luke Palmer wrote: No, you can't overload assignment at runtime because you can't overload assigment at any time, so says the language spec (well, not any formal spec; so says Larry as far as I remember). I'm wearing my just a programmer, not a denizen of p6l hat. Pretend I don't know the difference between overloading assignment and setting special STORE magic and I want the option to be able to have Array do something meaningful and significant to both of us when I assign a constant scalar to it. Again, I don't care *how* I accomplish it, as long as I don't have to root around in the source code of Perl 6 itself to make it work. As for the first argument, presumably people put type annotations on their code so that we can do some reasoning and tell them about errors. I don't want to use a module off of 6PAN that breaks my code because its type annotations have leaked out into the rest of my code and I have no idea what the compiler error messages mean. It's sort of the anti-$, except it can make my program run faster. (Correct answers: depends on the question. Wrong answers: instantaneous.) It's up to the person who *runs* the code, not the person who writes a component and can't possibly decide from now 'til forever exactly every circumstance in which he will allow people to use the component, to decide what level of compiler complexity and strictness to allow. If my program takes a second to run, I don't want to spend several seconds performing type checks more suited for a long-running program. If my program's a network-bound server process that ought to share most of its memory, maybe I don't want to JIT things. If I'm running the final customer tests before delivering frozen bytecode to customers who won't be changing the code, maybe I want as many checks and optimizations as possible. Making the author of a module decide that is wrong. Maybe allowing a module author to request stricter typing within the module is fine, but it oughtn't be the last word on the subject. I've programmed in languages that froze certain library code at a specific level of strictness for philosophical and speed-related reasons. It was painful when I needed to do something that the language designers and library developers never thought I might need to do. Sure, I have a just a programmer hat, but that doesn't mean I can't use well-encapsulated magic when I really need it. To make this concrete -- Java's final: broken, wrong, stupid. Pick three. Types are abstractions and all abstractions break sometimes. Of the possible analysis features the compiler can perform by default, I prefer to enforce sensible symbol names, as-small-as-possible scopes, and lack of near and exact duplication. These to me are much more useful than an optional-until-someone-somewhere-uses-it type system that prevents me from finding the escape hatches purposely built into the language. -- c
Re: Type annotations
On 10/7/05, chromatic [EMAIL PROTECTED] wrote: On Fri, 2005-10-07 at 17:43 -0600, Luke Palmer wrote: No, you can't overload assignment at runtime because you can't overload assigment at any time, so says the language spec (well, not any formal spec; so says Larry as far as I remember). Again, I don't care *how* I accomplish it, as long as I don't have to root around in the source code of Perl 6 itself to make it work. That's easy. Define coerce:as (Int -- Array) {...}. Don't define it after CHECK is run. As for the first argument, presumably people put type annotations on their code so that we can do some reasoning and tell them about errors. I don't want to use a module off of 6PAN that breaks my code because its type annotations have leaked out into the rest of my code and I have no idea what the compiler error messages mean. It's sort of the anti-$, except it can make my program run faster. (Correct answers: depends on the question. Wrong answers: instantaneous.) That's what this thread is about. We're trying to nail down the semantics so we know exactly how soft to be when an unannotating programmer imports an annotated module. It's up to the person who *runs* the code, not the person who writes a component and can't possibly decide from now 'til forever exactly every circumstance in which he will allow people to use the component, to decide what level of compiler complexity and strictness to allow. If my program takes a second to run, I don't want to spend several seconds performing type checks more suited for a long-running program. If my program's a network-bound server process that ought to share most of its memory, maybe I don't want to JIT things. If I'm running the final customer tests before delivering frozen bytecode to customers who won't be changing the code, maybe I want as many checks and optimizations as possible. Of course. To me, those seems like flags of the compilation (or running, since most of the time compilation will not be a separate phase). The only person who gets to specify those is the person who writes main.pl, because he has access to the #! line. I've programmed in languages that froze certain library code at a specific level of strictness for philosophical and speed-related reasons. It was painful when I needed to do something that the language designers and library developers never thought I might need to do. Sure, I have a just a programmer hat, but that doesn't mean I can't use well-encapsulated magic when I really need it. Once you start diving into the guts of another module, you should be prepared to start telling the compiler that it's wrong. I'm certainly not saying that you shouldn't be able to do that. Types are abstractions and all abstractions break sometimes. Of the possible analysis features the compiler can perform by default, I prefer to enforce sensible symbol names, as-small-as-possible scopes, and lack of near and exact duplication. These to me are much more useful than an optional-until-someone-somewhere-uses-it type system that prevents me from finding the escape hatches purposely built into the language. Okay. Some people find type annotations to be more useful than you do though. If you want to argue that Perl shouldn't have type annotations, go ahead. But for the moment, we're under the assumption that Perl has the ability to make type annotations, and that those annotations should have some affect on your program. And this thread is trying to decide what that effect is. Luke
Re: Type annotations
On Fri, Oct 07, 2005 at 12:50:09 -0700, chromatic wrote: On Fri, 2005-10-07 at 12:49 +0200, Juerd wrote: Ashley Winters skribis 2005-10-06 19:30 (-0700): my Array $a = 97; # dies eventually, but when? Runtime -- cannot coerce Int value to Array It is fully determinable at compile time. 97 will never be compatible with Array, so I see no reason to wait. If I added a multisub for Array assignment so that assigning an integer value set the length of the array, would 97 be compatible with Array? That's a compile time reachable analysis. If the compiler finds out that: a. no code will be evaled (due to 'use optimize' or just plain lack of require, eval etc in the code) b. there is no compatbile multisub then it should throw an error How about in unreachable code (which I do actually believe compilers can detect some of the time)? These errors should probably still persist, even if dead code is subsequently removed from the bytecode, because dead code can become undead code if certain things change (compile time foldable conditionals over e.g. $*OS are such a scenario) and the same program should be typed the same way everywhere for a given version of Perl. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me does a karate-chop-flip: neeyah!! pgpdHU54ECTW7.pgp Description: PGP signature
Re: Type annotations
On Thu, Oct 06, 2005 at 17:44:10 -0600, Luke Palmer wrote: Autrijus convinced me that we have to really nail down the semantics of type annotation without use static. Let's first nail down what I meant by semantics in that sentence. Basically, when do various things get checked? Run time or compile time (not coercion; I have a proposal for that coming). Oh, I'm asking p6l here, not Larry in particular. This part of the language is yet-undesigned, so some arguments one way or the other would be nice to hear. So we're in line one of a Perl program, with static typing/inference disabled (or at least inference *checking* disabled; perl may still use it for optimization). When do the following die: compile time (which includes CHECK time), run time, or never? my Array $a = 97; # dies eventually, but when? my Int $b = 3.1415; # dies at all? Both die at compile time, because the user explicitly contradicted him/herself. This is like saying my int = $x :: float; since they're constants and their types are very well known. sub foo (Int $arg) {...} foo(hello); # should die at the latest when foo() is called Immediately, at compile time, for every caller of foo unless 'no static' or whatever is active for that scope. However, no inferencing is made - this is just 1 level deep. sub bar (Int $arg -- Str) {...} foo(bar(42)); Since -- is explicit I'm not sure if it means infer this even if we're not globally inferring. I lean towards compile time error here since I think it would be nice to have that, but there are some disadvantages. Perhaps this should infer only in the lexical scope that 'sub bar' was defined in, to make sure that error reporting does not confuse naive users of the module that defines foo, without asking for compile time inference. sub static (Code $code, Array $elems -- Array) { [ $elems.map:{ $code($_) } ] } sub dynamic ($code, $elems) { [ $elems.map:{ $code($_) } ] } static({ $_+1 }, dynamic(notcode, [1,2,3,4,5])); dynamic(notcode, static({ $_+1 }, [1,2,3,4,5])); This is only with full inferencing, either lexically enabled as a a pragma (in the scope that invokes), or if enabled globally. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me does a karate-chop-flip: neeyah!! pgpZ0kQYyANwT.pgp Description: PGP signature
Re: Type annotations
On 10/6/05, Luke Palmer [EMAIL PROTECTED] wrote: So we're in line one of a Perl program, with static typing/inference disabled (or at least inference *checking* disabled; perl may still use it for optimization). When do the following die: compile time (which includes CHECK time), run time, or never? This is just my opinions as a Perl programmer in the trenches. I would expect Typed variables to auto-coerce themselves, but not impose fatality. Predictable auto-coercion would be nifty in quick-and-dirty programs. Ignore my advice at will -- nobody's required to use Types in their own code, so there's no need for them to be universally valuable. However, since I expect builtins and all standard functions to have fully declared Type signatures, consider how these decisions would affect _every_ program, before ordering the summary execution of everyone's poor little Perl script. my Array $a = 97; # dies eventually, but when? Runtime -- cannot coerce Int value to Array my Int $b = 3.1415; # dies at all? Doesn't die, $b == 3. Int scalars should coerce anything which can be prefix:+'d. sub foo (Int $arg) {...} foo(hello); # should die at the latest when foo() is called $arg should be undef but Exception::InvalidInteger(Str value 'hello' cannot be coerced to an Int at $?LINE) sub bar (Int $arg -- Str) {...} foo(bar(42)); If bar returns a Str ~~ /Perl6::Grammar::Int/, it gets coerced; otherwise, undef but Exception sub static (Code $code, Array $elems -- Array) { [ $elems.map:{ $code($_) } ] } sub dynamic ($code, $elems) { [ $elems.map:{ $code($_) } ] } static({ $_+1 }, dynamic(notcode, [1,2,3,4,5])); die Str value 'notcode' cannot be called as a Sub reference -- have you asked Larry how to make a symbolic function call, lately?; dynamic(notcode, static({ $_+1 }, [1,2,3,4,5])); Same. Just my 2ยข Ashley Winters