libera/#sicl - IRC Chatlog
Search
14:36:29
scymtym
the second item in the list following "A description of slot-options follows" in http://www.lispworks.com/documentation/HyperSpec/Body/m_defi_5.htm#define-condition looks like a TeX error, right? the postscript output also has a single bullet in the middle of an otherwise definition-style list
15:30:11
scymtym
the ide integration and improved CLIM browser make we want to add stuff again, though :/
15:33:11
beach
I keep thinking of the IDE. There are so many components that exist. If I could just think of a good way to compute indentation, then I think a demo version could be made.
15:36:37
scymtym
from my perspective, there is also a big chunk of unsolved issues in the architecture domain. in particular for integrating early compilation stages and environment maintenance with the incremental parsing. also showing and updating errors and analysis results in a sensible manner
15:36:59
scymtym
but i guess i have prototype-quality solutions for some of those so a demo could be in reach
15:37:43
beach
Right, and we have different ideas there it seems. I see the use of Cleavir/Clostrum/Trucler.
15:39:56
scymtym
right. at least for prototyping i wanted environments that can easily store arbitrary information (current package, information pertaining to the current readtable, etc) rather than something tailored to the language-level Common Lisp environments
15:40:10
beach
It would be like creating Cleavir-based compilers for existing Common Lisp implementations, except that there would be no pressure to generate fast code.
15:40:57
scymtym
there is also the question of whether the ordinary compilation stages should be adapted to work with non-CL:SYMBOL symbols or not
16:06:56
beach
Good progress today with code generation. There are some instructions left to implement, but I don't know exactly how many. A small number I think. Most instruction have been a matter of defining another method on a generic function.
16:07:02
beach
But a few minutes ago, I ran into the SAVE-VALUES-INSTRUCTION and I thin that one should result in a named call, so it will be a bit more involved to implement. I am not going to attempt that this close to dinner time.
16:07:10
beach
There are also some Cluster instruction descriptions missing, in particular LEA. But I think we are getting close to generating code.
16:07:11
beach
After that, there is the primitive call-site manager to implement, and also to write bytes to the simulated heap at the end of bootstrapping.
16:10:20
beach
scymtym: Also, with only Eclector + indentation + what you do with "simulated" environments, the analysis is better than what SLIME can do, so one could start with something like that, and then improve by adding more passes to the analysis.
16:10:43
beach
scymtym: What I am trying to say is that it is not necessary to do a full semantic analysis from the start.
16:13:18
scymtym
beach: yes, full analysis is not required, but i would like to start at a level where we know the meaning expressions and symbols in particular based on the surrounding forms
16:31:58
beach
By the way, did you see my utterances in #commonlisp where I am more and more convinced that current Common Lisp implementation are too easy to trash to be well suited to an in-image IDE? I think an implementation with multiple first-class global environments could come in handy, so that the user can trash the current environment, without affecting the one the editor is working with.
16:33:18
beach
I mean, it is still possible to execute an IDE in current Common Lisp implementations, of course, but it won't be as stable as some people might expect, given that it shares its global environment with the application(s) being worked on.
16:34:45
beach
With SICL, I want it to be possible for a programmer to trash some aspect of the global environment and either manually start a new fresh one, or get a new one automatically if the current one is no longer viable.
16:36:20
pjb
Note that 100% of the time, (minus epsilon), the state of the editor is persisted on files.
16:41:21
pjb
But for the last two difficult situations I had, one was due to an infinite recursion in an advice on message (in emacs), and the other was a problem with the order of binding and deleting a temporary package to *package*.
16:42:55
pjb
For the infinite recursion, what matters is the safe handling of storage-condition (and stack exhaustion). Having environments could have simplified recovering (some editing operations were impossible), but just correcting the code was sufficient: it wasn't a mutation of the implementation.
16:44:10
beach
pjb: You are right, of course, which is why I still think an IDE will be a valuable tool, even though the current implementations are not great in this respect.
16:44:29
pjb
For the binding to package, I guess that the debugger behavior is sufficiently implementation dependent that it can rebind *package* in case of problem (I think sbcl does it, even); but here it was unrelated to environments. The handling of conditions cannot be performed in different environment, only the debugger can run in its own environment.
16:45:53
pjb
In general, I've got the impression that stack overflows (infinite recursions can come from surprising places) are a bigger problem than mutation of the host system (the IDE or the implementation).
16:45:57
beach
I think we agree. I just wanted to point out that an implementation with first-class global environments would be ideal.
16:47:18
beach
And since I don't think there is any hope that any existing Common Lisp implementation will be completely transformed to use first-class global environments, SICL is probably the best hope for it to happen.
16:48:02
beach
My (admittedly small) family just announced that dinner is served. I'll be back tomorrow. Take care everyone.