freenode/#sicl - IRC Chatlog
Search
13:39:42
beach
Here is a scenario: The compiler sees a call to function F, so it calls the Trucler function DESCRIBE-FUNCTION. The object returned by Trucler contains the "flag" inline/notinline/nil and if it is INLINE, the object must also contain some data, like an AST for the compiler to use for inlining.
13:41:10
beach
Ultimately, if it is not a lexical function, DESCRIBE-FUNCTION is called on the compilation environment. So the client must define a method on that function. How does the client implement that method?
13:42:15
beach
Well, it starts by calling FUNCTION-INLINE on the compilation environment. Because if there is a top-level (DECLAIM (INLINE ....)) then FUNCTION-INLINE returns INLINE or NOTINLINE.
13:42:56
beach
If there is no such information in the compilation environment, it is possible that the function exists in the evaluation environment or in the startup environment.
13:44:18
beach
It is part of the startup-environment if the programmer has (proclaim '(inline ...)) before starting the compilation.
13:45:49
beach
And it is part of the evaluation environment if the programmer did (eval-when (:compile-toplevel) (proclaim '(inline ...))).
13:47:19
beach
So the function FUNCTION-INLINE first consults the compilation environment and then its parent, and then the parent of the parent, etc.
13:49:07
beach
Now, let us imagine what the method on the Trucler function DESCRIBE-FUNCTION does if FUNCTION-INLINE returns INLINE. It must then find the inline data (say AST) and store it in the FUNCTION-DESCRIPTION object.
13:50:53
beach
That will happen if the function F was defined using DEFUN in the same compilation unit, because then, F does not get created at compile time, but inline data for it must be stored, and that is what the compilation environment is for.
13:52:16
beach
If the inline data is not found in the compilation environment, it is possible that there was (eval-when (:compile-toplevel) (declaim (inline F)) (defun F ...)...) during compilation. So then the function F got defined in the evaluation environment.
13:52:59
beach
It seems reasonable to me that the inline data should then be associated with the function OBJECT, as opposed to being a separate entity the way it must be in the compilation environment.
13:53:56
beach
But client code decides how functions are represented, so Clostrum can't decide how that data is (are?) stored.
13:55:05
beach
So I suggest that Clostrum define a default method that returns NIL for INLINE-INFORMATION on the run-time environment.
13:56:14
beach
SICL will supply a method that does (sicl-mumble:ast (clostrum:fdefinition 'F environment)) because it will have a slot for the AST in the function.
13:56:38
jackdaniel
I think that clostrum (a protocol, as opposed to the example implementation), should not define the method at all - it may be accessible from the fdefinition or from somewhere else, but why a default empty method?
13:57:06
jackdaniel
it should only define a generic function and a terampoline from the evaluation environment
13:58:20
jackdaniel
from the specification I understood, that the evaluation-environment-mixin implements the same protocol as the run-time environment, but all methods are (or (call-next-method) (call-this-method (parent env)))
13:59:59
jackdaniel
I imagine, that as a rule of thumb it works fine, and if the client defines their own method then they can overwrite the default behavior
14:00:39
beach
Also, we don't have to be perfect from the start. Let's not let perfection get in the way of something reasonable.
14:01:15
jackdaniel
I'm not sure if you approve of such solution, but I've defined macros define-operator and define-accessor, which record run-time-environment protocol methods (and add some sanity checks to arguments), and then generate trampolines automatically
14:01:24
jackdaniel
as you can observe here: https://github.com/s-expressionists/Clostrum/blob/master/Code/clostrum.lisp
14:06:18
jackdaniel
so to summarize: we should update the specification wrt special-variable and constant-variable (return values), specify the function function-inline for the compilation-environment, and specify the function inline-information for both run-time-environment (and by inheritance, to evaluation-environment-mixin) and compilation-environment, is that right?
15:07:48
beach
This is a very interesting exercise, i.e. discussing the details of the different environments and their roles. In the end, I think this will be great! And by "this" I mean Clostrum, but also the use of Trucler, CST, Eclector, AST, and CST-to-AST for this entire phase in the compilation process.
15:11:05
beach
Speaking of which, I am thinking about what to do for compile-time EVAL. I think the idea I showed Harag for sandboxing will work. Since the compilation is done by CST-to-AST, we can invoke CST-to-AST recursively on the code to be evaluated during compilation, thereby producing an AST.
15:12:19
beach
Then we can translate that AST to Common Lisp code in a trivial way, except that a few things like FDEFINITION-AST will be translated into clostrum:fdefinition with the evaluation environment as its argument.
15:13:59
beach
Since the AST no longer has macros in it, it will just call functions. The client can fill the evaluation environment with whatever definitions of those functions it finds appropriate.
15:44:26
jackdaniel
since we've agreed that function-inline is not erased when the function is undefined, should it return error when it is not defined?
16:05:08
jcowan
I have a lot of sympathy for the ISLisp position that only a subset of the language is available in macros, though the subset is not very precisely specified.
16:11:05
jackdaniel
I don't like the idea of islisp at all, it brings nothing new to the table (it is basically a subset of common lisp)
16:11:19
jcowan
Yes: "The set of usable operations [in a macro expander function] is restricted to simple data structure creation and manipulation; those operations are forbidden that cause side-effects to the environment (such as I/O to the terminal), to externally accessible data structure (such as a modification to the property list of a symbol), or to the macro form itself." (clause 16)
16:11:43
jackdaniel
(unlike i.e eulisp which was being specified around the same time, never standardized though)
16:12:16
jcowan
ISLisp is intended to be non-reflective: in particular, there is no EVAL or COMPILE at runtime. However, you do need an EVAL at compile time in order to handle macro expanders.
16:12:17
pjb
jackdaniel: ISO Lisp has some cleanup that proponents of CL21 would like to have in CL…
16:14:28
jcowan
The idea of Lisps that are static (not in the sense of type, but in the sense of not being malleable at runtime) is an interest of mine.
16:18:04
jackdaniel
pjb: it is only syntactic sugar, they are special variables with separate forms and a namespace. I can see though that someone might like that. thanks
16:46:18
jcowan
After all, there are people like the author of Picolisp who think that CL betrays the spirit of Lisp malleability because you cannot mutate a function object at runtime, as you can in Elisp.
16:46:49
jcowan
So staticness is a continuum, with Picolisp almost at one end (you can even mutate a bignum if you insist)