<beach>
I wasn't very careful with the parameters of the screen recorder, so the file might be big.
<beach>
Indentation was (still is a bit) one of the major obstacles for me to use Second Climacs myself, and for the longest time, I didn't know how to deal with indentation efficiently and effectively.
<jackdaniel>
so this is a major breakthrough, congrats!
<beach>
Yes, I think so. Thanks! The hard part was to come up with some reasonable abstractions to avoid code duplication, and also to figure out how to deal with comments associated with code.
<jackdaniel>
are indentation rules hardcoded or they can be customized with an exported interface?
<jackdaniel>
(or at least - what are plans in this regard)
<beach>
Everything is customizable of course. :) Seriously, they will be, but I am not sure they are (yet). That's a minor thing to implement.
<beach>
For those who don't now, Second Climacs indentation is based on the buffer being parsed by Eclector, so it has much better information about the contents of the buffer than (say) Emacs does.
<beach>
In the example, declarations are indented a bit more. That's mainly just to show the capabilities of the technique.
masinter has quit [Remote host closed the connection]
<beach>
Now I have a dozen or more files with old (and bad) indentation code, that I will convert to the new technique used by LET in the example.
<beach>
And then I will attack the remaining special forms and standard macros, and some standard functions.
<pve>
Looks great! Does that mean that if I have a DSL macro, it would be possible to define indentation for that DSL? (A bit like LOOP, i guess)
<beach>
Absolutely. It might not be easy for complex things like LOOP, but certainly possible.
<pve>
That's really nice to hear
aartaka has quit [Ping timeout: 260 seconds]
<beach>
Though, ultimately, we will use the S-expression-syntax library to parse the expressions, and indentation will use the result of that parse.
aartaka has joined #commonlisp
<beach>
That library will also let you define rules for your DSL in a much easier way than the current indentation code, when the expression is complex like LOOP is.
<beach>
But, I had to do something temporary, waiting for scymtym to "release" that library.
rettahcay has joined #commonlisp
rettahcay has left #commonlisp [#commonlisp]
* scymtym
is still busy with Eclector stuff
<beach>
Sure.
<beach>
I think the S-expression-syntax library will be an essential component of any software that processes Common Lisp code on the S-expression level. And having one single library is going to be a major advantage that many client programs can take advantage of.
<scymtym>
the clasp people would like to have a new way of binding and querying the current readtable. i think this will be another rabbit hole, but in a good sense since i have been thinking about unifying binding, setting and querying different parts of the reader state for some time
<beach>
Excellent!
<scymtym>
should also help with representing the reader state in (delta) environment objects
<beach>
Yeah, that's essential.
<pve>
beach: How about if the DSL goes inside square brackets with a reader macro? Like (defun foo () (print [dsl code here])). Does it become more difficult in that case? (I can't tell)
<beach>
Not a problem. :)
<pve>
wow, great
<beach>
The parsed units are based on what the reader returns. So reader macros are taken into account.
<scymtym>
but seriously, that sort of thing /should/ work
<pjb>
pve: but you would use different parenthesis characters only if the syntax of your DSL wasn't S-expr.
<pjb>
pve: if possible, it's preferable to use S-expr, and introduce your DSL with a normal macro, instead of reader macros.
aartaka has quit [Ping timeout: 256 seconds]
<scymtym>
pjb: the questions was whether the Eclector-based parse result infrastructure used in Second Climacs would still work with such a DSL, not whether one can make such a DSL with the Common Lisp reader
<beach>
pve: Second Climacs works on nested parsed blobs called "wads". A wad is essentially the unit of return from Eclector. Second Climacs does not look at the contents of the buffer to determine meaning and things like indentation. It just uses those wads.
<pve>
pjb: right, I have a smalltalk-like dsl that I might put in [...], but I've always been bummed out with how emacs wants to randomly indent it :)
<beach>
pve: So if you have a reader macro (say) [ then what is read when that macro is invoked becomes a wad.
<pve>
beach: ok, I think I understand
<beach>
So the commands like forward-expression, backward-expression still work.
<beach>
Emacs, of course, can't do anything like that. At least not easily.
<pve>
sounds really promising
aartaka has joined #commonlisp
<beach>
Thank you. It was planned to be promising. But things take longer than expected (Hofstadter's law).
aartaka has quit [Ping timeout: 248 seconds]
aartaka has joined #commonlisp
ebrasca has joined #commonlisp
aartaka has quit [Ping timeout: 268 seconds]
Fare has quit [Ping timeout: 252 seconds]
<pjb>
For editor interface, each reader macro should be provided with additionnal parsing code.
aartaka has joined #commonlisp
waleee has quit [Ping timeout: 260 seconds]
<pjb>
In part this code could be infered automatically from actually reading the reader macro, but sometimes it may be difficult to match the text to the read form.
<pjb>
(notably when read-char is used with a custom parsing, instead of reading sub-sexps).
<scymtym>
pve: this doesn't have beach's new indentation, but you can see how the custom reader macro doesn't throw off the motion and editing commands: https://techfak.de/~jmoringe/second-climacs-3.ogv
<beach>
scymtym: Excellent!
<scymtym>
thanks
<beach>
Great demo!
<scymtym>
there are limits, of course. in particular things won't work as well if the reader macro returns some structure that is completely different from the structure of the recursive READ calls performed during the execution of the reader macro
<beach>
Right.
<_death>
hmm.. in the video, how do you know that ) is not expected (and ] is)?
<beach>
So I see you used the (relatively new) command EXCHANGE-EXPRESSIONS, yes?
<beach>
I am guessing the reader macro signals an error.
<pjb>
Reader macros can do very strange things, even reading a different file.
<_death>
they can do whatever #. can do..
<scymtym>
_death: the custom reader macro calls READ-DELIMITED-LIST with a suitable character. that character is used in the error message
<scymtym>
beach: yes, i think i actually had to fix a few things in EXCHANGE-EXPRESSIONS
<beach>
Heh, I see.
<_death>
scymtym: so that means there's eager reading in place? (like what's mentioned in KMP's article)
psvensso` has quit [Ping timeout: 260 seconds]
<scymtym>
_death: i have read that article at some point, but i can't remember now. do you have a link?
<_death>
well, I remember reading, but I see it talks about evaluation.. like interlisp/medley too, I believe
<scymtym>
right, thanks
<pve>
scymtym: looks very nice, I need to think about what the "there are limits" part means
<scymtym>
_death: i will read the article again but not now. in general, Eclector and Second Climacs try to behave like a conforming reader. this is easier said than done for Second Climacs due to incremental parsing, not interning symbols and other complications, of course
<beach>
pve: When a call to READ is made, Second Climacs registers the start and end positions in the buffer where the call was made, and it assumes that the text material in that region contains what was returned by READ. If the reader macro returns something completely different, perhaps shuffling the return values to multiple READ calls, then things won't work.
<scymtym>
pve: thanks and yes, depending on your DSL works, things may or may not magically behave correctly
jmdaemon has joined #commonlisp
Fare has joined #commonlisp
<pve>
ok, in my case I'd have something like:
<pve>
[ "Hello, " :concatenate-with person name ] => (smalltalk (concatenate-with/1 "Hello, " (name/0 person)))
<_death>
scymtym: cool.. it does seem the article is relevant, judging by the amusing "This COND branch failed." example
<beach>
pve: Things that don't depend on what is returned, like forward/backward expression will work as expected.
<beach>
pve: Second Climacs will "see" a wad for the entire expression containing 4 sub-wads.
<beach>
pve: But the indentation code might be very confused.
<pve>
heh
<beach>
... because it looks at the expression returned.
<beach>
You can then, of course, program the indentation code to recognize the expression returned.
<pve>
that's absolutely fine
<beach>
pve: But, this is a bit in the future. The immediate ambition is not to support arbitrary DSLs, but "just" to have a better analysis of "ordinary" Common Lisp code.
<pve>
I mean, it's awesome that it's even possible to support such esoteric things
<beach>
Thanks.
<beach>
The secret is to use a standard reader, as scymtym pointed out to _death.
<beach>
... whereas most editors use a parser that is different, and simplistic.
<Josh_2>
:trumpet: GM COOOO PEOPLE :trumpet:
_cymew_ has joined #commonlisp
seere has quit [Ping timeout: 255 seconds]
Fare has quit [Ping timeout: 252 seconds]
seere has joined #commonlisp
jon_atack has quit [Ping timeout: 260 seconds]
igemnace has quit [Remote host closed the connection]
jon_atack has joined #commonlisp
jon_atack has quit [Ping timeout: 246 seconds]
seere has quit [Ping timeout: 265 seconds]
seere has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 264 seconds]
Guest25 has joined #commonlisp
Guest25 has quit [Quit: Client closed]
aartaka has quit [Ping timeout: 248 seconds]
aartaka has joined #commonlisp
waleee has joined #commonlisp
rainthree has joined #commonlisp
Nilby has joined #commonlisp
morganw has quit [Remote host closed the connection]
harps has joined #commonlisp
jmdaemon has quit [Ping timeout: 252 seconds]
rainthree has quit [Read error: Connection reset by peer]
yottabyte has quit [Quit: Connection closed for inactivity]
ns12 has quit [Quit: bye]
ns12 has joined #commonlisp
jon_atack has joined #commonlisp
Josh_2 has quit [Quit: Gotta go fast!]
mathrick has quit [Remote host closed the connection]
mathrick has joined #commonlisp
harps has quit [Ping timeout: 260 seconds]
quoosp has quit [Ping timeout: 264 seconds]
tyson2 has quit [Remote host closed the connection]
amoroso has joined #commonlisp
jmdaemon has joined #commonlisp
Fare has joined #commonlisp
tane has joined #commonlisp
tane has quit [Changing host]
tane has joined #commonlisp
jon_atack has quit [Ping timeout: 264 seconds]
jon_atack has joined #commonlisp
McParen has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
aartaka has quit [Ping timeout: 252 seconds]
aartaka has joined #commonlisp
eddof13 has joined #commonlisp
Fare has quit [Ping timeout: 252 seconds]
aartaka has quit [Ping timeout: 248 seconds]
aartaka has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eddof13 has joined #commonlisp
epony has joined #commonlisp
varjag has joined #commonlisp
Gleefre has joined #commonlisp
jon_atack has quit [Ping timeout: 252 seconds]
ttree has joined #commonlisp
Fare has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 28.2]
varjag has quit [Ping timeout: 265 seconds]
Fare has quit [Ping timeout: 255 seconds]
glaucon has quit [Read error: Connection reset by peer]
varjag has joined #commonlisp
jon_atack has joined #commonlisp
aartaka has quit [Ping timeout: 260 seconds]
morganw has joined #commonlisp
aartaka has joined #commonlisp
jeosol has quit [Quit: Client closed]
bilegeek has joined #commonlisp
Fare has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
attila_lendvai has quit [Ping timeout: 252 seconds]
jon_atack has quit [Ping timeout: 252 seconds]
aartaka has quit [Ping timeout: 260 seconds]
aartaka has joined #commonlisp
azimut has quit [Ping timeout: 255 seconds]
attila_lendvai has joined #commonlisp
Inline has joined #commonlisp
aartaka has quit [Ping timeout: 248 seconds]
ebrasca has quit [Remote host closed the connection]
pve has quit [Quit: leaving]
amoroso has quit [Quit: Client closed]
karlosz has joined #commonlisp
Inline has quit [Quit: Leaving]
shka has quit [Ping timeout: 246 seconds]
Cymew has quit [Ping timeout: 260 seconds]
Fare has quit [Ping timeout: 252 seconds]
_cymew_ has quit [Ping timeout: 268 seconds]
tane has quit [Quit: Leaving]
tyson2 has joined #commonlisp
McParen has left #commonlisp [#commonlisp]
Fare has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jon_atack has joined #commonlisp
Fare has quit [Ping timeout: 252 seconds]
jon_atack has quit [Ping timeout: 268 seconds]
son0p has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
semz has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
semz has joined #commonlisp
Gleefre has quit [Ping timeout: 260 seconds]
eddof13 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
eddof13 has quit [Client Quit]
harps has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
varjag has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
waleee has quit [Ping timeout: 246 seconds]
akoana has joined #commonlisp
jon_atack has joined #commonlisp
karlosz has quit [Quit: karlosz]
tyson2 has joined #commonlisp
jon_atack has quit [Ping timeout: 268 seconds]
harps has quit [Ping timeout: 248 seconds]
morganw has quit [Remote host closed the connection]