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
