freenode/#lisp - IRC Chatlog
Search
17:39:11
_death
I think a good followup question you should have, with beach's model in mind, is why symbol-function and friends don't take an environment parameter
17:50:11
_death
also, weaker association between names and objects (first-classization) is something that appeals to many scheme-minded people
18:04:21
pjb
_death: that's because they're the standard API. (defun symbol-function (sym) (sicl:symbol-function sym sicl:*environment*))
18:06:02
_death
pjb: the begs the question.. I asked about the standard functions.. I agree that it's due to historical reasons
20:43:35
phoe
minion: memo for pfdietz: There's a comment I've made at https://github.com/phoe/package-local-nicknames-tests/pull/2 - did you have any insight about it so far?
21:14:30
phoe
Will the compiler then inline the code for these functions only in LOCALLY's lexical scope?
21:14:45
phoe
Like, if I declare A, B, C locally inline, and A calls B, and B calls C, will everything get inlined?
21:15:41
phoe
To define a function f that is not inline by default but for which (declare (inline f)) will make f be locally inlined, the proper definition sequence is:
21:24:54
phoe
If a function is locally inlineable, am I also able to compile it with different optimization settings?
21:25:23
phoe
Like, will I be able to compile it locally inline with speed 3 if the original function is compiled with speed 1?
22:41:24
pjb
phoe: you're doing something wrong: asking an implementation dependent question in #lisp instead of #sbcl or something.
5:00:40
gilberth
I believe the environment concept of CL is undervalued. I abused macros in my CLIM to implement presentation types in a way, that mere compilation of a file would not harm the current image.
5:01:43
beach
Interesting. For SICL, I definitely intend to make the compilation environment separate from the startup environment to avoid such side effects.
5:01:46
gilberth
As compilers, that I found, are careful about that, defining a macro in a file to be compiled does not make it to run time until loaded.
5:03:51
gilberth
I have a namespace concept. It should definitely be possible to spawn new name spaces which "behave".
5:05:55
gilberth
Macros do that in practice. My definition of FIND-PRESENTATION-TYPE essentially calls MACROEXPAND on a specially named symbol in the environment at hand. Which is a hack. But then SETF-functions are a hack too in all CL implementations, I know about.
5:09:35
gilberth
You could go lexical, if you want. I stick the definition of a meaning of a symbol in certain namespace to its macro expansion. Which is a hack. But it works well and manages to get the behavior, that compiling a file does no harm, given current compilers.
5:10:27
gilberth
The symbol then is named like (<namespace> <name>) Like e.g. |(PRESENTATION-TYPE FOO)| and that is the hack.
5:15:08
gilberth
Anyhow: My point is: It should be possible to spawn a new name space in "user" space, which behaves. Like for instance our presentation types. It is a pain in the a**.
5:15:54
beach
gilberth: It will be possible in SICL, as my paper on first-class global environments shows.
5:18:13
gilberth
It is even worse, because: I want to be able to rename packages and load multiple versions of a system. Then the scheme CL-USER::|(SETF FOO) would have been saner. If you ask me.
5:18:22
beach
I will need all that functionality anyway in Second Climacs. I need for every top-level form to be compiled in a "delta" environment that can be discarded without great cost.
5:19:09
beach
gilberth: It is straightforward to do with my first-class global environments protocol.
5:21:46
gilberth
CL is Lisp-n and still has poor support for that. I had quite some fun to get the presentation type stuff right by abusing macros.
5:22:44
beach
gilberth: The problem is not in Common Lisp itself. The problem is that current implementations take the easy way out.
5:23:15
Bike
well it's true the language doesn't have any convenient mechanism for adding to the environment.
5:24:03
gilberth
beach: I contradict. How would you span a new name space? So that it could have lexical definitions and the property, that the compile time set of defintions could be different from the run time definitions?
5:24:42
gilberth
beach: I abused the macro name space and embedded the presentation types into it by a pure naming convention.
5:25:27
beach
All I am saying is that the standard defines different environments, like the startup environment and the compilation environment.
5:26:05
beach
But then, to make existing implementations conforming, it had to allow for all of those to be the same.
5:26:12
gilberth
beach: That is fine. Very fine. And I love it. Yet, I have no easy and well defined access to it, when I need a new name space.
5:27:03
beach
If the standard had included such access, all existing implementations would be non-conforming.
5:28:19
gilberth
Sorry. Althrough a lot of implementations are poor about that issue. I happen to believe, that is not the issue. How would you define a name space for say presentation types? You'd start with a hash table, right?
5:30:04
gilberth
beach: What I need is a mapping from the pair of the environment and the name [what ever that'll be] to a definition.
5:30:50
gilberth
And if that environment is just the compilation environment without the result being loaded, fine with me.
5:32:09
gilberth
beach: I may be a good hacker, but I could not hack everything at once. Clone me and wait for that person to mature. I think that would be a better plan :)
5:34:17
beach
2. Start including modifications that all implementation (or nearly so) include anyway.
5:34:59
beach
4. Define yet another standard update that requires the separation of the startup environment and the compilation environment.
5:37:13
gilberth
Actually, somebody should have the guts to write down CLtL3. It is a low hanging fruit actually: We have defacto standards: Gray Streams, MOP, bivalent streams, multithreading [through sequence points are hard, very hard].