On Fri, Nov 04, 2005 at 08:14:11PM +0100, TSa wrote:
: HaloO,
:
: Larry Wall wrote:
: >On Tue, Oct 25, 2005 at 10:25:48PM -0600, Luke Palmer wrote:
: >: Yeah, I didn't really follow his argument on that one. I, too, think
: >: that the one() junction in general is silly, especially for types.
: >
: >Well, I think it's silly too. I'm just trying to see if we need to
: >reserve the syntax in case someone figures out a way to make it
: >unsilly in some dialect.
:
: So, here are three non-trivial types that make excelent use of the
: one() junction:
:
: 1) The parse tree of a packrat parser
: 2) a n-ary, recursive decision tree
: 3) a multi method
:
: I wouldn't call these silly :)
Hmm, yes, one might even go as far as to put 4) union types.
: >And that's why I'm kind of
: >pushing for a natural bundling via juxtaposition that can be viewed
: >as ANDing the constraints:
: >
: > :(Any Dog Cat Fish ¢T $dc)
: >
: >That says much the same thing as
: >
: > :($ where {
: > .does(Any) and
: > .does(Dog) and
: > .does(Cat) and
: > .does(Fish) and
: > .does(Class) and ¢T := $dc.class and
: > .does(Scalar) and $dc := $_;
: > }
: > )
:
: This is a very nice way to avoid explicit infix & syntactically,
: which is a great achievement in its own right. BTW, does a sub
: name in there count as a type constraint?
Which "in there" are you referring to? Syntactically the inside of
a "where" is an ordinary expression, so "Dog" has to be predeclared
or use :: on the front.
: Or are only package kinds applicable? I mean the ones that would get
: a :: sigil if the sigil were required.
If you mean the "where" expression, the inside of .does() is just
evaluating an ordinary expression, so you could certainly put a sub
call or anything else in there. If you're asking about the proposed
stacked type constraint syntax, I don't think a sub will work there
because of syntactic ambiguity with wanting to declare &blocks
and such.
Larry
