freenode/#sicl - IRC Chatlog
Search
9:06:32
beach
Somewhere, very likely programmatically generated, I have a (DECLARE (DECLARE...)) somewhere.
9:07:13
beach
Before CST was fixed by Bike, it ignored this declaration, because it didn't recognize the type of declaration.
11:31:52
scymtym
this seems suspicious assuming DECLARATION-CSTS actually holds CSTs: https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir2/CST-to-AST/convert-let-and-letstar.lisp#L106
12:29:35
scymtym
beach: sure, i thought this was a good opportunity to put the s-expression pattern matcher to work
13:21:09
Bike
i should probably change cst to signal an error on declare declare, since it's definitely illegal
13:24:37
Bike
Well, what error are you getting? I would expect CST to treat the DECLARE as a type declaration
13:33:58
beach
So (declare (declare (ignore))) has been transformed into (declare (type (declare (ignore))))
13:43:00
beach
Then it calls MERGE-TYPE with the client, with the description (i.e. NIL) and the type (i.e. DECLARE).
13:44:00
beach
MERGE-TYPE specializes on the description, so the default method is called, which calls error.
13:49:47
beach
OK, so we have an ordinary list of CSTs, each one being a CST version of (declare ...).
13:53:40
beach
But if there are declarations, we build (let <bindings> (declare (declare ...) (declare...)) RESULT) instead.
13:56:48
Bike
wouldn't doing (cons (cons 'declare (mapcar #'rest declarations)) result) work too? so (declare x) (declare y) becomes (declare x y)
14:01:43
beach
Just wrap declaration-csts, so that they turn into (mapcar #'cst:rest declaration-csts).
14:14:03
beach
*SIGH* the entire day is almost gone, and I haven't started my "mission", i.e. think about the global environment protocol for use with Trucler and Cleavir.
14:22:16
heisig
beach: If you need someone to discuss the global environment protocol, I'll be around most of the evening.
14:28:21
beach
So the client of CST-to-AST must define methods on those functions, specialized to whatever global environment it gives to CST-to-AST.
14:29:59
beach
And Trucler may well receive a function description describing a generic function, even though Trucler is not really concerned with generic functions.
14:31:25
heisig
As I said before, I'd recommend that the global environment library provides methods such that each global environment can also be used as a Trucler lexical environment.
14:33:10
heisig
Every query function has a fallback method that queries the global environment instead, using the global environment protocol.
14:34:27
beach
Trucler has default methods on those that just adds a lexical environment layer, right?
14:35:43
beach
And, both the client of CST-to-AST and Trucler itself may call a query function, passing a global environment, right?
14:36:13
beach
I mean, that client just calls the query function, at there may not be any lexical environment piled on top.
14:39:32
heisig
I think of it as GLOBAL-ENVIRONMENT inheriting from LEXICAL-ENVIRONMENT. Except both environments are opaque objects and inheritance might not be involved at all.
14:40:51
heisig
The global environment argument might even be ignored for a potential native-global-environment client.
14:43:27
beach
Right, but nothing prevents us from asking the client to supply a dummy object. And I think we should.
14:43:57
beach
Methods specialized to the class of that object would just trampoline to global functions.
14:54:49
beach
I think the way to attack this problem is to ask the question "what does CST-to-ASt ever need to query the environment about", and then we can take the answers and stick them into two categories: 1. purely global and 2. maybe lexical or global.
14:57:36
beach
We know about DESCRIBE-VARIABLE, DESCRIBE-FUNCTION, DESCRIBE-BLOCK, DESCRIBE-TAG, and DESCRIBE-OPTIMIZE.
14:58:25
beach
Trucler currently has DESCRIBE-CLASS, but the association between a class name and a class is always global.
14:59:46
Bike
i don't think there's good reason to exclude the possibility of an implementation that allows information that is standardly only global to be lexical.
15:01:02
beach
OK, fair enough, but that would have to be transparent to these protocols, because we can't possibly think of every such situation.
15:02:45
Bike
yeah basically what i mean is that i think it would be good for the compiler to be able to treat environments uniformly as far as possible.
15:03:05
Bike
CST-to-AST calls global-environment in a couple places but maybe we can eliminate that?
15:03:22
Bike
we can for example distinguish lexical versus global function references by the type of info returned by the query function
15:03:38
Bike
and that's actually what we do, but conver-global-function-reference gets the global environment as an argument
15:04:56
beach
OK, so now be basically have a conflict. According to you, when the compiler needs a list of DECLARATIONS, it should call a Trucler function. But heisig wants to avoid that.
15:09:01
beach
CST-to-AST has its own environment generic functions, like DECLARATIONS (or maybe DESCRIBE-DECLARATIONS) and DESCRIBE-FUNCTION..
15:10:28
Bike
a query method for DECLARATIONS on a lexical environment could just pass to the parent environment
15:12:18
beach
You explicitly wanted to avoid functionality that is only related to the global environment.
15:12:22
Bike
Yesterday I said global and lexical environments should have separate protocols but I'm rethinking that
15:14:12
heisig
The difference is that a global environment protocol will also have to provide functions for querying the current value of a special variable ant the like.
15:15:21
Bike
so maybe what i want is a distinction between "compile-time environments" and "runtime environments". and the latter might use some of the former functions, like for macros, out of convenience
15:17:09
Bike
i don't know about putting accessors in the compiler. other things might want to use them.
15:17:59
beach
That protocol is documented and client code must define methods on the generic functions of that protocol.
15:18:36
beach
A client of CST-to-AST must determine whether it wants to use Trucler or something else for lexical environments.
15:18:56
beach
The CST-to-AST protocol does not distinguish between lexical and global environments.
15:20:07
Bike
Maybe we should separate Trucler the protocol from Trucler the implementation of lexical environments, and then use Trucler the protocol in CST-to-AST.
15:21:13
heisig
And for augmentation, I recently introduced an environment builder protocol that seems to work well.
15:25:01
heisig
beach: Or, put differently, how would this CST-to-AST specific protocol differ from Trucler?
15:37:09
beach
It would have a DESCRIBE-DECLARATION function in it that would query the global environment for the information.
15:38:29
beach
Currently, I have code in CST-to-AST (Cleavir 2) that must determine whether to call a direct function in Trucler, or just to get the global environment, and then it doesn't know what to do with the global environment object.
15:39:12
beach
With this indirection, an implementation that (as Bike suggests) want to do lexical stuff, in this case, introduce lexical DECLARATIONS would modify the method I am talking about.
15:39:56
beach
And that would not influence Trucler, which would just do its standard lexical environment stuff.
15:40:28
beach
Other advantage: A client of CST-to-AST that doesn't want to use Trucler is then free to use whatever it finds suitable.
15:41:27
beach
CST-to-AST declares to the outside world that "this is the kind of information I will need from the environment".
15:42:23
beach
But it should have no opinion about what technique (Trucler, native, whatever) the client of CST-to-AST wishes to use to supply this information.
15:45:04
beach
I suggest we sleep on this suggestion. And Bike is (or was) not quite up to date about how Trucler works, so that might be something to sleep on as well.
15:46:40
beach
Now, I vividly remember feeling uneasy when I changed all invocations of cleavir-env:something in CST-to-AST in Cleavir 2 to invocations of either trucler:something-else or (not-sure (trucler:global-environment environment)).
16:02:34
Bike
i thought trucler was a protocol. if a cst-to-ast client wants cst-to-ast to use native environments it would just define trucler methods for native environments
16:05:37
heisig
This, in turn, would finally end the code walking horrors of the last decades, because everyone could just use AST walkers instead.
16:08:07
beach
Bike: Trucler is three things. 1. It is a protocol for managing lexical environments, like a working and modern version of the protocol suggested in CLtL2.
16:08:36
beach
2. It is bunch of implementations of that protocol for existing Common Lisp implementations, like SBCL, ECL, Clasp, etc.
16:09:26
beach
3. It is an implementation of that protocol using its own representation of such lexical environments, and that implementation can be used by fresh Common Lisp implementations, like SICL.
16:14:05
beach
I think I said this. Because heisig does not think information only relating to the global environment ought to be part of Trucler.
16:14:44
beach
An implementation using its own lexical environments, and allowing lexical (declare (declaration...)) will define a method on cst-to-ast:define-declarations, that interrogates the lexical environment.
16:16:03
beach
Because we can't include in Trucler every possible function that every possible implementation might want to use in the future.
16:17:16
beach
heisig: What about the functions CLASS and METHOD-CLASS on a GENERIC-FUNCTION-DESCIPTION?
16:19:54
beach
Though, we can do that if you like, i.e., make Truckler define every function that CST-to-AST will ever need in order to interrogate the environment.
16:23:17
heisig
But that specific client could then simply create its own subclass of GLOBAL-FUNCTION-DESCRIPTION with that metadata attached.
16:23:25
beach
But Trucler needs to return a generic-function-description when describe-function happens to be a generic function.
16:24:19
beach
But I said every environment query that CST-to-AST will ever need in the future, for all extensions of all implementations.
16:26:31
beach
heisig: OK, so I accept that it is OK with you to include DESCRIBE-DECLARATIONS in Trucler because some implementations may need to interrogate the lexical environment.
16:26:53
beach
Now we have an implementation that allows lexical generic functions and lexical compiler macros.
16:28:05
Bike
even if there are lexical generic functions, i don't think cst-to-ast needs to know about them
16:28:50
heisig
beach: That implementation can subclass Trucler's descriptions and provide two additional generic functions. Where is the problem?
16:29:10
heisig
That is exactly what I do to provide access to SBCL specific metadata on trucler-native.
16:31:14
heisig
So people can call trucler-native-sbcl:deprecated to find out whether the current description names something that is deprecated.
16:32:44
beach
We just add the one or two missing things that CST-to-AST needs to Trucler, and we are done.
16:36:45
Bike
the reason i was thinking about lexical compiler macros is that actually i put some stuff in clasp's compiler macro on FUNCALL to look for compiler macros for the function being called (e.g. for setf), and found that cleavir-env:compiler-macro signals an error on local function infos instead of returning NIL like i expected
16:39:30
heisig
beach: What cases would DESCRIBE-DECLARATIONS cover that are not already covered by DESCRIBE-OPTIMIZE and DESCRIBE-[VARIABLE|FUNCTION|CLASS]?