[EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
> About this point was when my brain when "a ha!". But I'm not yet
> convinced that generating all possible parses is (a) of sane time
> complexity, and (b) a little *too* DWIM for its own good.
As I said, I wasn't sure whether or not I was being serious at this point.
> > > method bar($x, $y) {
> > > method bar($z) { # note 1
> > Oh, bringing in multimethods Just Isn't Fair.
>
> Those are multimethods? Migod, I feel like a person who's just
> discovered for the first time in their life that the plate that gets
> passed around in church is for putting money *onto*.
Oh, if you have a method which does X when it gets one argument and does
Y when it gets another, I'd call that a multimethod. But then, I am no
OO wizard.
> Let's try and be pragmatic[*] here. If we stick to the following
> subset of the problem space:
> - no multimethods
> - all method signatures known through predeclaration
> - no method name has two different signatures in the same class hierarchy
>
> (all of which can be determined at compile-time), then there should only
> be one possible legal parsing for any particular method call or
> pipeline of method calls.
Yes! I agree! However, there is a problem.
We have determined that, in a dynamic language, the actual method lookup
is done at runtime. That is, we don't know what method we're going to call
until runtime. That is, we don't know what method we're going to call until
well after the method call statement has been parsed.
If your head isn't spinning yet, remember that some evil coder may
(conditionally) replace the method during the program's run, leaving us
with the halting problem.
> Can we dictate that parentheses are optional in this case, and demand
> parentheses in all others?
You see, the problem is that if we don't know what method we're going
to call until way after we've parsed the code, (which I hope we've
just proved above) we don't know how many parameters it's going to
take. And if we don't know how many parameters it's going to take
until we run it, we have next to zero chance of working out how many
parameters it's going to take when we compile it. Which was the basis
of my semi-serious notion of caching the whole set of possible parses.
Which means that parens really can't be optional in this case.
Except that this all sprung from my idea of having a block passed
directly to a method without the other arguments being
involved. (Which would work without parens, optional or
otherwise. (because it works exactly this way in languages like Ruby
(but most Perl 5 people can't get their heads around that (which is
why this idea is facing a dead end.))))
> [*]
Hey, what *was* note 1, anyway?
--
LARTing lusers is supposed to be satisfying. This is just tedious. The
silly shite I'm doing now is like trying to toothpick to death a Black
Knight made of jelly.
- Red Drag Diva
