freenode/#sicl - IRC Chatlog
Search
13:27:39
beach
heisig: Shall I update the Test directory for the HIR evaluator to use Clostrum-based environment, or should I just remove that directory now that the evaluator is used by the bootstrapping procedure?
13:33:50
heisig
And even if I decide to resurrect the test suite at some point in time, we do have version control for that.
13:35:37
pjb
heisig: I beg to differ, bootstrapping is not enough of a test. It's a minimal test, but you will want to test also things that are not used while bootstrapping.
13:39:16
heisig
pjb: You are right. But I am a proponent of lazy coding. I will resurrect the test suite once we run into problems with the HIR evaluator for the first time.
16:16:29
beach
So right now I am working on removing the obsolete system SICL-GLOBAL-ENVIRONMENT. Some functions need to be adapted to the new system, and the new ideas. In the past, I had code such as DEFUN access the environment directly with using ENV:FDEFINITION etc.
16:16:36
beach
Not anymore. They should all go through the standard function now. And if no standard function exists, I invent one. The purpose of this way of doing it is so that I can undefine the environment functions.
16:16:37
beach
To define something like CL:FDEFINITION, I do (let ((fdefinition-function (...))) (defun fdefinition (name) (funcall fdefinition-function ... name))) so that the environment function is closed over.
16:17:40
beach
So the idea is 1. Create an environment with the environment functions defined. 2. Load definitions of the standard functions that use them. 3. Undefine the environment functions.
16:18:51
beach
So of course I also did something stupid. During bootstrapping, I carefully avoid importing the environment functions, and instead I create special definitions of the standard functions "manually".
16:19:39
beach
Instead I should 1. Import the environment functions from the host. 2. Load definitions of the standard functions that use them. 3. Undefine the environment functions.
16:21:08
beach
There will of course always be one "superuser" environment that has the environment functions defined, but it will not be the default environment.
17:36:20
beach
Yes, and yes. But for Scheme, the evaluator also needs to be modified, because the rules are different. Shouldn't be too hard though.
19:13:15
beach
ebrasca: You can nest environments if you like. They are just any old objects. So you can define a special variable in one environment that has another environment as its value. But what would be the point? We already know that things are not hierarchical, and that hierarchical file systems are a kludge to make it acceptably fast to search for files in computers from the 1960s.
19:26:45
beach
This is why CLOSOS does not have a hierarchical object system or file system or environment system.
19:34:34
ebrasca
If envirements can become any language , what if language a is implemented by language b?
19:36:14
beach
I don't see how that is related to environments (which are just mappings from names to objects). The Scheme specification does not mention what language an implementation must be written in.