freenode/#lisp - IRC Chatlog
Search
4:04:59
beach
black_13: What is the purpose of your S-expression parser, and why do you need to write one?
4:07:29
beach
black_13: The reason I am asking is that Common Lisp comes with a built-in S-expression parser. It is called READ.
11:00:40
no-defun-allowed
Silly question: when quickloading something, what do all the dots signify (other than looking nice)?
11:05:28
no-defun-allowed
Ah yeah, I was guessing something like each top level form, but that seems easier to track.
11:07:00
minion
jmercouris, memo from pjb: You need a reader macro, you cannot do it with a macro (because then you won't need what symbols were qualified). You cannot use #. because you need the input stream; when loading or compiling a file, *standard-input* is not set to the source stream!
11:07:00
minion
jmercouris, memo from pjb: https://pastebin.com/qJTUxwYc (note: !?{}[] as (dispatching) reader macros are reserved for the user, so don't use them in code published in quicklisp)..
11:07:47
no-defun-allowed
Yep, does seem to be like that. I wrote a little system that just prints out the macroexpand-hook and it is in quicklisp-client::macroexpand-progress-fun
11:16:56
Xach
no-defun-allowed: no output at all for minutes could be alarming - has something failed?
11:20:07
no-defun-allowed
Can you eyeball it and say something like "that system has a lot of dots, it's pretty big"?
11:22:32
no-defun-allowed
(I ask since I loaded up CLIM, which loaded flexichain, and it scared the crap out of me because I intend to refactor it, and it put a lot of dots.)
13:19:12
pfdietz
The quicklisp macroexpand hook also prints the package name when a defpackage form is encountered, when a file being compiled.
13:23:04
ck_
quick, write the paper! "On Extending Software Metrics: Beyond Cyclometric Complexity. The Quicklisp-Dot"
13:25:58
pfdietz
There was an effort once to connect software complexity metrics to bug count. As I recall, the only interesting correlation was with code size.
13:56:19
warweasle
I've become the "the lisp guy". Every time a "new" idea shows up on /r/programming...I mention how lisp had it decades ago. Apparently they hate lisp there.
13:57:36
jmercouris
I think fundamentally a huge barrier to Lisp's adoption is indeed the absence of a GUI toolkit
13:59:32
jmercouris
web frameworks exist, then again, Python doesn't have a good GUI toolkit, and it has proliferated like crazy
14:01:47
p_l
jmercouris: looking back in time, Python ~2002 gave people the equivalent of paying for boxed set of MCL or Genera back in 1990, in the form of attached docs
14:02:42
p_l
but in the "the box comes with three-ring binders / books full of docs, a self-guide tutorial, and a good enough set of basic libs"
14:02:55
beach
jmercouris: I don't believe for a second that the existence of a GUI toolkit for Common Lisp would have any significant impact on its adoption. Strong psychological forces are at work here, and a GUI toolkit can't compensate for those.
14:04:49
beach
jmercouris: The easiest thing to do is to stop desiring more widespread adoption. I am convinced there is nothing we can do as Common Lisp developers to change it. It would have to be changed in university education, and even that may be too late.
14:05:32
p_l
beach: I'd say availability of a *complete* environment, one where people actually worked to keep that completeness, would drive a lot. But all such projects are expensive
14:06:26
beach
p_l: I seriously doubt it. I have studied the psychological forces involved and I have a pretty good understanding of their force.
14:07:29
beach
mason: The semantic gap between a language such as Common Lisp and a language such as C++ is so great that debugging becomes complicated and it influences in negative ways the programming style.
14:07:48
warweasle
p_l: Lisp will mutate to that. That's its best ability. To modify itself to become better.
14:08:34
p_l
warweasle: I heard MCL was a step-down from Delphi when it regards GUI. And it was goddamn good for lisp environment
14:10:30
mfiano
Interesting McCLIM hasn't been brought up, being as powerful as it is and local to Common Lisp.
14:10:38
beach
mason: It is already usable, but it has some of the same problems as Common Lisp itself, in that it requires people to change the way they have traditionally worked.
14:11:24
warweasle
beach: I think we need to start thinking in new ways. Like why is my text editor, language and compiler all separate?
14:11:46
p_l
aindilis: the kind of people that read actually insightful technical press is already the 1%
14:12:06
aindilis
warweasle: well you probably don't want to rule out their use of other programming languages, right?
14:12:07
warweasle
Imagine being able to make a C function, test it in your editor with some lisp and slowly create your project that way.
14:12:37
jackdaniel
it requries more work of course, but it works for interactive testing C functions
14:12:48
warweasle
jackdaniel: I did something similar...but it's weird that emacs is a completely separate piece.
14:13:30
jackdaniel
and scymtym took it and actually parsed stdio with success, what is a huge "wow", because C preprocessor is a mess
14:13:40
warweasle
There is that new fancy compiler. but it's been a while since I've looked into it.
14:14:26
jackdaniel
and regarding CLIM, we are moving forward with determination and stable progress
14:14:36
beach
warweasle: There are plans for an IDE with a very capable text-editor part that can analyze Common Lisp code in ways that are currently not possible, with a real debugger in which you can set breakpoints even in code that is itself executed by the debugger.
14:16:50
aindilis
what about making the Common Lisp static/dynamic analysis stuff a separate API that can be accessed by multiple editors?
14:16:59
mfiano
It would have to be better than stickers for me to switch. That blows SLIME debugging out of the water
14:20:42
beach
To analyze the contents of a text-editor window, we need to do several things that aren't possible (or at least not simple) with current Common Lisp implementations.
14:20:50
mfiano
Yes, LSP alone wouldn't be enough for Common Lisp. You would also need the DAP protocol, and additional editor specific functionality since LSP is not really suitable for interactive languages. Once you start adding editor specific functionality though, you no longer have what makes LSP useful - portability.
14:21:31
beach
Then we need a compiler that can handle incremental first-class environments, so that we can back out side effects when the code changes.
14:22:03
beach
But that is being worked on as well. :) In fact, most of such a compiler already exist.