freenode/#sicl - IRC Chatlog
Search
17:47:43
beach
So, CLEAVIR-ENV has a generic function DECLARATIONS, and so does SICL-GLOBAL-ENVIRONMENT.
17:48:48
beach
Now, I can't remember what our policy with respect to Trucler is for functions that does not have anything to do with lexical environments.
17:49:33
beach
But it seems silly for Trucler clients to also need to be configured for the kind of global environment that it is going to use.
17:51:05
Bike
well i did see a global-environment function, that takes a lexical or global environment and gets you a global environment
17:52:04
beach
But then what does Cleavir do with that environment if it doesn't know whether it is a SICL environment, a Clasp environment, an SBCL environment or what?
17:55:15
beach
CST-to-AST does not rely on the SICL global environment protocol as far as I can tell.
17:56:31
beach
Then the client of Cleavir, i.e. Clasp or SICL defines methods on Trucler generic functions that it needs for CST-to-AST to handle specially.
17:57:06
beach
... or 2. We have two different protocols. One has to do only with lexical environments, i.e. Trucler.
17:57:38
beach
But we also have a separate protocol for global environment that CST-to-AST relies on.
17:58:18
beach
I guess that in order to determine whether 1 or 2 is the best, we would have to determine how big the additional protocol would be.
17:58:55
beach
If it is small (which I suspect it is), then the simplest thing is to incorporate those functions into Trucler.
17:59:30
Bike
global and lexical environments are distinct enough that separating the protocols makes sense to me. i thought that was part of the idea of trucler, actually
17:59:38
beach
And just require the Cleavir client to define methods on Trucler generic function, just like we do now with CLEAVIR-ENV.
18:00:46
beach
And it would be the subset of the SICL-GLOBAL-ENVIRONMENT protocol that a compiler might need.
18:01:55
beach
So I guess I have to start by determining the functionality of this additional protocol.
18:02:58
beach
As I recall, we had this discussion when i needed to incorporate information about generic functions required by the paper on make-method-lambda.
18:03:32
Bike
I think it's pretty likely that a client would want to put its own information in the global environment, but less likely to want its own lexical environments
18:03:46
beach
It does make sense to have a separate protocol. I think that in the past, I was unable to distinguish it from all of SICL-GLOBAL-ENVIRONMENT.
18:05:11
beach
OK, so such an additional protocol would also be what Trucler would access in order to answer certain questions about a lexical environment.
18:05:32
Bike
having the lexical environment entirely internal to the compiler probably wouldn't be good, though, since it can end up in macro functions and stuff
18:06:59
beach
heisig already defined methods on Trucler functions for SBCL native lexical environments.
18:08:11
beach
So Trucler is the mediator between CST-to-AST and the lexical environments used by the client of CST-to-AST.
18:08:50
beach
But Trucler also proposes its own "reference" implementation for CST-to-AST clients who don't care, or who don't have their own, like SICL.
18:11:19
Bike
i mean, it's kind of how cleavir-env works, but there have been a few times i've had to use internal symbols
18:14:01
beach
OK, tomorrow I'll start listing the functionality that CST-to-AST + Trucler would need in order to access information in the global environment.
18:38:26
heisig
I agree that there should be separate protocols for global environments and for lexical environments.
18:39:07
heisig
However, every global environment should also be a valid lexical environment - the null lexical environment.
18:40:42
heisig
Which, luckily, shouldn't be too hard. One can just implement the Trucler protocol with the global environment protocol.
18:41:57
heisig
One for global environments, that is not concerned with lexical environments at all.
18:42:36
heisig
And a second one - Trucler - that weakly depends on the former and provides access to the lexical environment.
18:43:26
heisig
With the small extra feature that Trucler will handle any augmentation function on a global environment by returning a lexical environment.
18:45:58
Bike
i feel like an augmentation function would probably be insensitive to the nature of the parent anyway
18:49:20
heisig
The global environment could also provide a native-client, similar to Trucler. It would be much easier to write, because it can just use SYMBOL-FUNCTION, FBOUNDP and the like.
18:52:17
heisig
Another fun thought: Once I finish trucler-native, can I use it to write a portable version of EVAL?
4:25:01
ck_
beach: [no action needed on your part] I did most of what we discussed about the floating printer (good thing too, because it revealed a bug in the clhs-conforming code). I didn't touch the variable names, but put in some documentation strings instead. If you ever use it, I'd like to know :)
4:29:13
ck_
beach: so like I told the mcclim people, I'd like to say thanks to you as well. Not everyone is so welcoming.
4:33:46
ck_
You said, if I recall, in #lisp that "by end of year" is the current planning for an executable sicl?
4:34:23
beach
Yes, I just wanted enough time, but still push myself a bit. And I needed a well defined date.