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) {...}


    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.  :-)


Reply via email to