freenode/#sicl - IRC Chatlog
Search
13:37:21
Bike
i thought i might try fixing CST to handle destructuring optional and key parameters correctly, but the parser is a bit difficult. Why are destructuring lambda lists handled with their own thing and not, like, "symbol | destructuring-lambda-list"?
14:26:37
Bike
hm... the regular class hierarchy doesn't work, since destructuring parameters don't have "names"
14:29:12
Bike
there's a 'parameter' class and it has a "name" slot for the varialbe name. I could repurpose that as a destructuring-lambda-list, i guess.
14:29:32
Bike
there's a destructuring-parameter class but it doesn't actually appear in parse trees, so i'm not totally clear on what it's for
15:50:15
beach
I remember saying that all SICL functions are instances of FUNCALLABLE-STANDARD-OBJECT, but I don't recall whether I stipulated some subclass of FUNCALLABLE-STANDARD-OBJECT for ordinary functions.
15:57:44
MichaelRaskin
Intuitively I would expect SIMPLE-FUNCTION to be the class of what DEFUN normally produces
15:59:52
beach
MichaelRaskin: There is no SIMPLE-FUNCTION in the standard. Are you saying you prefer that name to ORDINARY-FUNCTION?
16:01:57
heisig
Then again, what would be the behavioral difference between funcallable-standard-objects and {ordinary|standard|regular}-functions?
16:03:36
MichaelRaskin
beach: I know there is no such thing in the standard as the standard doesn;t mandate that functions interact with CLOS, but this is the name I would expect to see if it did.
16:05:18
beach
The question is rather whether generic-function and ordinary-function are distinct or not
16:06:38
beach
I think that is sane, so that funcallable-standard-object would be a superclass of both, and so that clients can create new interesting subclasses of funcallable-standard-object that are distinct both from ordinary functions and generic functions.
16:11:37
heisig
I don't like 'ordinary' or 'regular'. It implies using generic functions is extraordinary.
16:12:25
beach
Recall that I arrived at this idea of SICL functions being FUNCALLABLE-STANDARD-OBJECTs because they are represented as standard objects and they are funcallable. Re-reading the Common Lisp HyperSpec, I realized that built-in classes are used only for objects with unusual representations. For SICL, that means FIXNUMs, CHARACTERs, SINGLE-FLOATs, and CONSes. There are other built-in classes with no direct instances, of course, such as
16:34:56
Bike
I have locally fixed CST to treat optional and keyword destructuring parameters correctly. easier than i thought, considering i barely understand the parser
16:35:13
Bike
unfortunately i found we're not declaring everything ignorable enough, and that's going to take some more substantial changes i think
16:36:27
Bike
and i'm testing in sbcl, which is good, because clasp wouldn't have warned me about unused parameters
16:37:41
Bike
Here's the problem. When we generate bindings for a lambda list, we have one "argument-variable" that's the argument list we haven't bound yet. We declare that ignorable at the top level, in parse-macro.
16:37:59
Bike
But if we have a nested lambda list it has its own argument-variable that also needs to be declared ignorable at top level, so that needs to percolate up somehow
16:38:57
Bike
the easy way to do it would be a dynamic variable, but i feel that would be against the style, so instead the functions that return bindings should return a list of variables to declare ignorable as well