freenode/#sicl - IRC Chatlog
Search
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)