thoughts about types, and possible syntax for code as comment

[Stéphane Payrard]

I expect Perl6 to be a language with a mix of dynamically typed and
statically typed variables. In a purely statically typed language like
OCAML, you generally don't need to declare the type of variables
when it can be inferred. So one can benefit from the speed of static
typing (no type info must be handled at run-time) without the chaff of
often redundant type annotations. This has a price though, when
running into a typing problem, the compiler often gives cryptic errors.
But things are probably more complex in Perl6 with a mixed
static/dynamic type system.

Given the complexity of type inference that makes it indecidable in
many complex case, will it be possible in Perl6 to omit some type
annotation in some declarations and expect the compile to infer the
types at compile time? Probably, this will not be supported in
the early versions of Perl6, but is this something even possible?
With ou without help from the programmer with some sort of pragma?

In many cases, and especially when omitting type annotations, the
programmer need a long and descriptive name for parameters. This
is ackward when the said parameters are heavily used.
The long descriptive name is useful for the declaration but goes
against the Huffman principle.

# with type annotation, it is obvious what $xp is
sub canon( Expr $xp ) { }

# ...not anymore
sub canon( $xp ) { }

# ... so one would use a longer name
sub canon( $expr ) { }

# But sometimes the parameter name conveys more info than restating
# the type; that often means even longer names

sub canon( $subjet, $complement ) { }
sub canon( Expr $subjet, Expr $complement ) { }

To get an huffmanized name and a clear one, I would like some support syntax:

sub canon( $subjet as $s , $complement as $c ) {
# code with lots of $s and $s
}

# or without type annotation
sub canon( Expr $subjet as $s , Expr $complement as $c) { }

One could even drop the sigil in the short form with the signature:

sub canon( $subjet as s , $complement as c ) { }
sub canon( Expr $subjet as s , Expr $complement as c) { }

I could not stress enough the value of code as comment. It cannot fall
so much in touch with reality as code evolve than pure comment always
does. Worse, the ratio code/comment can be such that one cannot get
much real meat in a screenful.

I cross post to perl6-compiler because the question about type
inference in a language which a mix of static/dynamic type is very
much a implementation feasability question. Probably after going thru
"Types and programming langauge" by Benjamin C. Pierce and learning
about OCAML implementation, I will have a better grasp on type
inference.

--
stef

[Larry Wall]

On Thu, Jan 06, 2005 at 11:07:47PM +0100, Stéphane Payrard wrote:
: To get an huffmanized name and a clear one, I would like some support syntax:

:
: sub canon( $subjet as $s , $complement as $c ) {
: # code with lots of $s and $s

: }

Aliasing can currently be done with the binding operator:

sub canon( $subjet, $complement ) {

my $s := $subjet;
my $c := $complement;
# code with lots of $s and $c
}

: # or without type annotation

: sub canon( Expr $subjet as $s , Expr $complement as $c) { }

If we put syntactic relief into the signature, it'd probably work the
other way around, where the descriptive parameter name is the optional thing:

sub canon( Expr $s is named<subjet>, Expr $c is named<complement>) { }

That way the sigil is on the variable, and not on the parameter name that
you'd use in a named call:

canon( subjet => $mysub, complement => $mycomp );
canon( :subjet($mysub) :complement($mycomp) );

We could conceivably allow a declarational notation like:

sub canon( subjet => Expr $s, complement => Expr $c) { }

: I could not stress enough the value of code as comment. It cannot fall

: so much in touch with reality as code evolve than pure comment always
: does. Worse, the ratio code/comment can be such that one cannot get
: much real meat in a screenful.

I agree, but it's also easy to fall into the COBOL trap where not much
real code fits on a screenful, even without comments.

On type inferencing, I think it's fine as long as it's used primarily to
give better error messages or gain performance. But if it increases the
mental load on the naďve programmer, it's perhaps too much of a good thing.

[If we're going to discuss either of these things extensively, they should
probably be broken out into separate threads.]

Larry