Pyli/Unresolved Issues

Top:	Pyli
Up:	Pyli
Prev:	Pyli/Introduction
Next:	Pyli/Naming Conventions

Unresolved Issues

There are some things I am still thinking about that I am not really committed to yet.

Compilation

Sometime in the near future, I am going to have to add a compile step to the interpretation process. Will that require that I nail down a good set of symbols so that I don't have to look them up every time? Or is it enough to have the symbols refer to something that is compiled?

Named Parameters or only ordered parameters?

Adding named parameters adds significant complexity, but it is really nice. However, I don't miss named parameters in langauges like perl and Javascript since I can always use a dict. I don't think I will include named parameters.

Compromises:

☠ Perl: Perl doesn't have parameters. Every method gets an @_, which is the parameters in a list. You handle them the way you think is best, or not at all. This requires building a vector for each function call, even if the arguments aren't used at all. Although I like this method a lot for its simplicity, it isn't very powerful. However, combined with a good set of apply-args functions, functions that will appropriately setup the lexical environment, it could be quite useful. The problem remains, however, that the function signature is opaque.

☠ ☠ ☠ Python: Python is probably the worst solution, forcing every function to accept both ordered and named parameters. This is why function calls are expensive in python. Although the result is powerful, it is too expensive and complicated.

☠ Last-minute: If we know what the parameters are ahead of time, we can apply them as we evaluate the parameters. This would be accomplished by making all functions macros (which don't evaluate the arguments by default), and then having the first action being to interpret the args. This allows function to evaluate all the args, some or them, or none of them. I really like this method, although it makes the world more confusing.

★ call method is special: In this scenario, the object that is first in vector (the operator) is checked.

• If it is an internal function, it is called with all the rest of the arguments evaluated.
• If it is a pyli function, it is called after apply-args is performed against the argument list and a new environment is setup.
• If it is an object, it's call method is called with all the rest of the arguments evaluated, as a Vector. The function must call apply-args, or their own variant. This will allow you to create special kinds of functions that will interpret the arguments in strange ways.

Destructuring

I really, really, really like destructuring. If I am using ordered params, then destructuring should be applicable to function calls. But allowing destructuring and typing and optional params... that's a bit more difficult although CL does a good job keeping it simple.

☠ ☠ ☠ All functions as generic methods

So, when you define a function, it registers that function with that name. When you call a function, it will lookup the best match and call that one.

How does it match? I will have to dig into the way that CLOS handles generic methods and see if it is good enough or if it needs to be simplified. Having generic methods is a really good way to allow the built-in methods to be extended without having to define __add__, etc...

I'm not going to do this. I am going to lean more heavily towards traditional methods, ala Python, Ruby. However, I am not going to go all out and make everything a method. Some functions really don't belong as a method, even though they have arguments. For instance, sort.