On Fri, Aug 19, 2005 at 06:42:04PM +0300, Yuval Kogman wrote:
: On Fri, Aug 19, 2005 at 08:27:38 -0700, Larry Wall wrote:
:
: > Plus I still think it's a really bad idea to allow intermixing of
: > positionals and named. We could allow named at the beginning or end
: > but still keep a constraint that all positionals must occur together
: > in one zone.
:
: This is something I think code style should take care of.
:
: I would probably put all of my named "nouns" in the begining,
: positional nouns after that, and named adjectives at the end,
: because that's usually their order of importance for me.
That's not a problem as long as you keep your positionals together.
: If there is some really odd code signature which takes in a mess, I
: may want to intermix positionals and named's in order to increase
: readability.
This is Perl 6, which means it'll be trivially easy to implement
no strict "positionals";
or whatever you want to call it.
: In both these scenarios I see no use in the language limiting me
: "just because"... I think this is a reiteration of the "I'm not
: stupid, Perl should give me credit" issue.
I think it's really easy for newbies to confuse themselves this way,
and that's where strictures are most useful.
: > ...since another little niggly inconsistency is that we'd be marking
: > named params with : on the call side but + on the receiving side.
: > I hate to say it, but the named args should probably be marked
: > with : instead of + in the signature.
:
: I agree
:
: > Not sure what that does to
: > invocant colon though.
:
: Invocant colon as a metaphor is nice for
:
: method $object : ....;
:
: But I think that kinda sucks for
:
: new Dog; # uh, didn't you mean 'new Dog:;'?
The colon makes no difference there.
: And I personally never ever liked it in in signatures.
The use of colon as the SMD invocant marker is actually just a
degenerate case of MMD tiebreaking syntax.
: I would much rather see it go away, frankly, and let the issues be
: resolved by simplifying the OOP system. *cough*, *cough*.
Well, I can see the appeal of optimizing for the implementor rather than
the user. A lot of languages have already tried that... :-)
On the other hand, I'm not all that attached to colon itself. If,
as proposed elsewhere, we get rid of the %Foo:: notation in favor of
some Foo<> variant, then trailing :: becomes available (ignoring ??/::
for the moment), and
new Dog:: tail => 'long'
almost makes sense, insofar as it kinda looks like it's marking Dog
as a type name, even though it isn't. But
new Dog:: :tail<long>
doesn't look so good.
On the other hand, looking at it from the other end, the MMD notation
tiebreaking notation is a little hard to spot, since colon is easy
to miss. Maybe there's something that shows up better in a signature
that also works as the invocant marker and, by extension, the indirect
object marker. Since it's an ordering kind of thing, you'd kind of
like to work > into it somehow, since the left side is of "greater"
importance than the left. Unfortunately, though, "the good ones are
all taken". Maybe some digraph like
method new ($what*> $:tail) {...}
method new ($what+> $:tail) {...}
method new ($what.> $:tail) {...}
method new ($what|> $:tail) {...}
method new ($what>> $:tail) {...}
giving
new Dog*> :tail<long>
new Dog+> :tail<long>
new Dog.> :tail<long>
new Dog|> :tail<long>
new Dog>> :tail<long>
I guess that last one is eqivalent to:
method new ($what» $:tail) {...}
new Dog» :tail<long>
which I could maybe get used to. It kind of looks like a prompt to me.
The ordinary MMD might look like
multi foo ($a, $b, $c» $d)
And Lisp-like MMD fallback on every argument would look like
multi foo ($a» $b» $c» $d»)
I suppose that particular use of » could be construed as encouraging
people not to do that. :-)
Larry
