freenode/#sicl - IRC Chatlog
Search
8:00:13
heisig
I will try to get some more work done on Trucler this morning. Afterwards, I will be on a one week vacation to https://www.summer-breeze.de/en/
8:07:37
heisig
There is a generic function MAKE-ENVIRONMENT-BUILDER, that takes a client and an existing environment, and returns an environment builder.
8:09:35
heisig
The generic function FINALIZE-ENVIRONMENT-BUILDER takes a client and an environment builder, and returns a new environment.
8:10:09
heisig
This new environment contains all entities that have been added to the environment builder with ADD-*.
8:11:15
heisig
A macro WITH-ENVIRONMENT-BUILDER is provided that hides the calls to MAKE-ENVIRONMENT-BUILDER and FINALIZE-ENVIRONMENT-BUILDER.
8:19:33
scymtym
heisig: if the interaction with the builder is hidden anyway, would WITH-AUGMENTED-ENVIRONMENT or similar be a better name?
8:23:42
heisig
scymtym: The usage will be (with-environment-builder (builder) (add-lexical-variable client builder name identity) ...), so the builder is not really hidden.
8:24:43
heisig
But I agree the name is not perfect. The purpose of the macro is to return the final environment, and WITH-FOO macros are usually not used for their result.
8:28:21
heisig
Oh, and I don't plan on breaking Cleavir 2, especially not before going on vacation for a week :)
8:30:14
heisig
But one day, Cleavir 2 could use the new protocol to avoid allocating a dozen environments for each LET binding. If that turns out to be a bottleneck.
8:37:50
scymtym
heisig: is there a parent environment or is the intended use building environments from scratch?
8:39:09
heisig
scymtym: Yes, there must be a parent environment (which I forgot to pass to the macro).
8:43:56
heisig
Forget about the macro, I see now that it adds more confusion than value. The important part is the environment builder protocol.
12:26:03
beach
samlamamma: I created Cleavir version 2 because I had some fairly radical changes that I wanted to make to Cleavir version 1, and I did not want to break the code of my only client (which is Clasp). People say I could have used GIT branches, but I always mess up when I try to do that.
12:29:57
heisig
beach: Ok, I'm off for vacation. It seems I don't have permission to push to Trucler, so I submitted everything here: https://github.com/robert-strandh/Trucler/pulls
12:35:18
beach
samlamamma: The reference for first-class global environments is here: metamodular.com/SICL/environments.pdf
12:36:59
beach
1. Safety. As it is, any application code can modify the guts of the compiler and create unsafe code. I needed a way to control that in SICL, and (especially) in CLOSOS later on.
12:39:07
beach
3. Bootstrapping. I needed to be able to load and compile SICL Common Lisp code into a host Common Lisp implementation, even though that code defines standard Common Lisp operators, so that it would overwrite the host version of the operator if loaded into the host global environment.
12:40:02
beach
4. Multi-user capability. I need for CLOSOS to be a multi-user system, and I needed a mechanism to isolate users from one another.
12:42:14
beach
But first-class global environments also solve the versioning problem. Different versions of a system or a package can be loaded into different first-class global environments.
12:43:20
samlamamma
Without having read the paper, I assume there would be a way to communicate between different first-class global environments? I'm imagining some sort of remote-call protocol
12:44:18
beach
I think it would be done by having features from one environment selectively imported (perhaps with different names) into another environment.
12:46:54
beach
Environments are resolved at load time, so once code is compiled, it makes no sense to execute it in a different environment, other than if it has explicit references to that environment. I did that so that I could have the same performance of code with first-class global environments as without. Other suggestions for similar functionality pay a heavy price by having to use a hash-table lookup for each function call.
12:48:35
samlamamma
Yeah, that's a much better solution :-). SICL is an exciting project, even though I can't contribute myself I sometimes `make' the papers section and read stuff that seems interesting!
13:22:03
alandipert
i'm working on a new implementation targeting JS and curious about cleavir, do i need most of the language working before i can use it? or is there a subset i can target
13:28:11
beach
So either you do what Clasp does, i.e. have an interpreter for the language written in some other language, and then, at some point, replace it with a Cleavir-based compiler. Or you can do what SICL does, which is to execute Cleavir in a host Common Lisp implementation in order to generate the code that you want.
13:29:04
beach
If you are targeting JS, I imagine you can generate JS files to load into an existing JS implementation.
13:32:39
beach
It is probably more difficult for Clasp and SICL, because the execution environment must be created somehow. Clasp uses C++ to create a subset of it, whereas SICL generates (or it will) the full code for the execution environment also by executing Cleavir code in a host Common Lisp implementation.
15:09:12
beach
I have no idea how to test the result of translating HIR to MIR. I mean, I can look at the result of some small examples in the visualizer, but I don't see a way I can execute the result, short of writing an emulator for a processor with a memory.
18:20:14
karlosz
well, MIR semantics isn't so clear to me yet. is it supposed to have storage allocation done yet?
18:30:10
karlosz
well, given that there are like 40 lisp/scheme implementations that target C and 1 that target llvm-ir i wouldn't be so sure
18:30:44
karlosz
C is a really easy target because the C compiler actually gives more useful errors that llvm-as
18:32:36
karlosz
yeah, high level structs are nicer that declaring the memory layouts yourself... it could be quick and easy to simulate a VM by translating MIR to C and defining the memory layouts quickly a la Lisp in Small Pieces