develooper Front page | perl.perl6.compiler | Postings from January 2005

thoughts about types, and possible syntax for code as comment

Thread Next
From:
St├ęphane Payrard
Date:
January 6, 2005 14:07
Subject:
thoughts about types, and possible syntax for code as comment
Message ID:
20050106220747.GE6571@cachan-2-82-67-232-89.fbx.proxad.net
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









Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About