[Grace-core] minor language issues

[Andrew P Black]

On 18 May 2015, at 14:28 , Michael Homer <michael.homer at ecs.vuw.ac.nz> wrote:

> I'm not clear on why the arity checks are so objectionable; can you
> elaborate? I know you want to overload methods by arity, which isn't
> currently possible*, but checking arity seems an implicit part of
> parameter binding anyway.

Can I elaborate?  Sure.

If we didn't have variable arity methods, then the number of arguments in a request and the number of parameters in a method would both be statically known.  So there would be no need to explicitly check these numbers in the preamble of a method.  

For example, the request 

	print "hello"

has one argument list, of length 1, so we can say that it's a request of print(1) where the number(s) in the parens are the arities of the list(s).  A matching method body would have the same name, with the same number(s).  So a single string match in method lookup can find the correct method and check the arity correspondence.

However, since we have variable arity methods, such a simple scheme won't work.  We either have to abandon the idea of using simple matching to combine arity checking with dispatch, or we have to have the simple scheme fail, and then come up with a backup scheme for the variable arity case.  (This might be OK; variable arity methods are rare.  We could have a second method dictionary for variable arity methods, and consult it only when the first one fails.  But inheritance still has to work correctly, so it gets complicated ...)

I didn't write about this at length because we agreed long ago that difficulty of implementation should not be a reason for abandoning a good idea, or ease of implementation for adopting a bad one.  On the whole,  variable arity methods seem better than the alternative, which is to privilege one kind of collection by giving it a special syntax.  

	Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150518/f286f9d9/attachment-0001.html>