freenode/#lisp - IRC Chatlog
Search
21:02:14
scymtym
fiddlerwoaroof: if you like linedit, would this be interesting for you: https://techfak.de/~jmoringe/linedit-1.ogv
21:13:43
scymtym
phoe: yes, eclector-based highlighting. more or less the same thing that did the highlighting in the eclector presentation
0:57:12
fiddlerwoaroof
I tend to think of DI more as "passing arguments to functions" than "dynamic variables"
0:57:50
fiddlerwoaroof
Spring's XML stuff or Guice might be more like dynamic variables, but those are both abominations
0:59:54
fiddlerwoaroof
One way to do DI in lisp is "defun over lambda" (defun (dep1 dep2) (lambda (&rest other-args) ...))
1:02:16
fiddlerwoaroof
scymtym: that video is cool; my only objection is there's no code for me to try out...
1:03:56
scymtym
fiddlerwoaroof: i can try to publish an initial version tomorrow. i just didn't want to put too much effort into a thing that i wouldn't use myself
1:05:30
fiddlerwoaroof
scymtym: yeah, makes sense, I have a "lisp-sandbox" repository on github for this sort of demo
1:09:44
fiddlerwoaroof
One thing that would be useful with eclector is a more intelligent way to diff CL code
1:11:38
fiddlerwoaroof
git supports custom diff tools, and a syntax-aware diff for CL would be really helpful
1:13:45
fiddlerwoaroof
Interesting, I've looked for this every couple months and never run across an implementation that would work.
8:28:17
frodef`
beach: btw, is the general approach SICL to conceptually live "inside" or "outside" the parameters of CL?
8:29:49
frodef`
do you thing of the CL environment as a "subsystem", or is the CL environment the "end goal"...
8:29:55
no-defun-allowed
To do things outside the scope of of Common Lisp? Well, sure, there's threads, atomics, weak values, networking, so on and so forth, which weren't always de-facto standard. So everyone lives outside Common Lisp.
8:30:19
frodef`
(sorry again for such a imprecise question, I'v obviously not thought it very well through.)
8:32:15
no-defun-allowed
Having a good CL environment with as much stuff as possible would be the end goal to me.
8:33:21
beach
frodef`: I do want a conforming and strict Common Lisp implementation, but there is plenty of other functionality needed. And I also want to explore all the ways the standard allows in order to simplify the code.
8:33:42
no-defun-allowed
Or do you mean that the Lisp environment is a subsystem of a larger programming system, with an external editor, a profiler, a version control system, and other tools?
8:36:18
frodef`
how about a system that is "good" (i.e. "great!") and also just reasonably compatible with CL programs?
8:36:51
no-defun-allowed
I want to work on putting "modern" stuff like high performance IO and concurrent programming tools in Common Lisp, but in a way that doesn't completely mess up my programming style, and if I have to hack an implementation to get it to work, it will most likely be SICL when it's ready for that.
8:37:35
beach
frodef`: That is certainly an option, but I don't want that to be the only thing. I do want to create a good Common Lisp system for people who are currently Common Lisp programmers.
8:38:24
beach
frodef`: The problem is mainly that I am not smart enough to change the language. I just don't have the experience that the good people who wrote the standard did, even back then.
8:42:03
no-defun-allowed
The way I see it, making breaking changes not only leaves you with the pieces if something goes wrong, it leaves you with everything else which is now broken if everything goes right.
8:42:13
beach
frodef`: The first-class global environments is such a thing that it is transparent to conforming Common Lisp programs, but it gives a whole new tool if the programmer wants to go beyond the standard.
8:44:13
beach
I am still not sure whether your question was answered, but I hope you have some more hints. What was the reason for your question?
8:44:16
no-defun-allowed
Although hardly related, I have this opinion after a discussion with my favourite co-author about "Why Turtl Switched From CL to JavaScript" <https://lisp-journey.gitlab.io/blog/why-turtl-switched-from-lisp-to-js/>, in which the author was mainly stuffed, because they began writing asynchronous code, and had to either patch in, or completely rewrite, all this synchronous stuff that already existed.
8:46:07
frodef`
I do think CL have some warts and shortcomings. Warts like e.g. the sequence functions that I sometimes see as both awkward to use and incurs extra O(N) performance hits.
8:46:55
frodef`
beach: reason being general interest and trying to understand the SICL project, combined with my own related experience I guess.