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.
14:23:22
beach
And that compiler has sophisticated CLOS protocols that makes it possible to adapt to several implementation. We just need the manpower to make it happen. Or alternatively, significantly more time.
14:26:00
p_l
beach: I'd say fifty/fifty. The problem is that it's non-trivial amount of money, and some of the skills necessary are kinda low availability on the market due to general IT stupidity
14:26:57
beach
LdBeth: Most of the work I need done requires someone who is an expert in CLOS, in compiler design, and in software engineering, I am sure there are Lispers out there that correspond to that list of requirements, but they are very likely employed, have families, houses, friends, etc.
14:26:59
warweasle
p_l: I agree with you. I have to use ECL as a sort of scaffolding to develop C and C++.
14:27:17
mfiano
It's non-trivial to have a central documentation repository that doesn't just scrape docstrings. Quickdocs for example doesn't include #'(setf documentation) documentation. A near-complete solution can only be realized at compile time. Heck, #'documentation is a generic function and could change according to the local environment or at runtime.
14:28:11
p_l
for general CL betterment, there's a ton of ancilliary work that is unrelated to advanced programming itself
14:29:06
beach
warweasle: See out paper on first-class global environments. Also see the WSCL project.
14:30:45
mfiano
You would need to write your own reader and also takes some of the idea's from beach's paper to secure it.
14:31:24
LdBeth
mfiano: one has to assume there’s a period of time the system is stable and documents can be retrieved
14:32:08
warweasle
beach: I wish I had time to help on something. But I'm trying to start something for myself.
14:32:57
aindilis
I have omega number of projects going on, and omega + 1 = omega, so it wouldn't be any more work for me
14:35:02
beach
But, let me say this again, even when we have something decent, it won't have any significant impact on the number of people using Common Lisp.
14:36:15
mfiano
LdBeth: Correct. Any solution for fetching documentation is a partial one though. To be complete it has to be pushed by the author to a central repository, not the other way around, in order to better deal with foreign dependencies not available on the central repository, etc.
14:36:28
beach
aindilis: Only a deep transformation about what is taught at universities. And that's not going to happen because the teachers an insufficiently trained as well.
14:37:06
aindilis
I do have a text -> concordance wiki system I wrote that could aggregate links to mentions things like SICL, Cleavir, McCLIM a bit, WSCL, Clordane, Second Climacs, etc into a Wiki, maybe even google them for additional mentions, and then disambiguation of multiple denotations?
14:38:57
warweasle
beach: I had an idea using an sexp-based diff tool to create something similar to git. We could build documentation, annotations, etc into the system.
14:39:47
warweasle
As a bonus, this system could be used as an editing tool...like the heart of a distributed text editor.
14:40:43
aindilis
warweasle: git is insufficient? replicating something as complex as git would be difficult I would think
14:41:18
aindilis
it would be cool to have an index of who has what projects, and to see where people are aligned and could team up
14:41:26
warweasle
Git is just diff and patch with hashing. This would allow you to create documents within documents.
14:42:57
aindilis
I worked on a now defunct project called POSI to coordinate what people were working on by having them list their goals, and coordinate to achieve them: https://frdcsa.org/~andrewdo/writings/flourish-2009.odp
14:43:36
aindilis
the main innovation was using RTE (recognizing textual entailment) / NLI (natural language inference) to figure out which goals were identifical
14:44:14
warweasle
My end idea was to use "safe-lisp", this sexp-database/revision mangager interface and some gui tools to create new applications based on your data. As you need them.
14:49:06
warweasle
LdBeth: Similar to basic javascript. It can't interact with anything outside itself. Unless you plug in something like a DOM or some other connection.