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
