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
