<mrcom>
It's a simple little quiz about EVAL-WHEN. When you compile, and then load, this fragment, what prints?
<mrcom>
No fair running the code.
robin has quit [Read error: Connection reset by peer]
<beach>
I suppose you mean compile using the file compiler, yes?
pve has joined #commonlisp
<mrcom>
Yep. In slime ^C^K, or (load (compile-file "x.lisp"))
<beach>
But you never call the macro FOO anywhere?
<mrcom>
Not in this question.
amb007 has quit [Ping timeout: 256 seconds]
<beach>
So then the macro expands to something like (setf (macro-function 'foo) (lambda (form envrionment) ...))
amb007 has joined #commonlisp
<beach>
*environment
<mrcom>
Yeah, depending upon the compiler.
<beach>
So then none of the forms in the body is a top-level form.
<mrcom>
But this question is about the debug-io calls. Which ones actually print?
<mrcom>
That's that conversation we were having. Which I'm still confused about...
<beach>
The "whatever" is executed only when the macro is invoked, so not at compile time or load time.
<mrcom>
The result, from the last form, yes. What gets spit out from DEFMACRO processing and evaluating?
pillton has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3)]
<mrcom>
Spit out, as in which of the debug-io calls are executed, at which point. Not the usual macro definition.
ym has joined #commonlisp
<beach>
Since the body forms are not top-level, "compile" is not printed and "load" is not printed, neither at compile time nor at load time.
mesuutt has joined #commonlisp
<beach>
:EXECUTE makes the EVAL-WHEN turn into a PROGN, so the macro, when invoked, will contain a form that prints "execute" but not at compile time nor at load time.
<beach>
For the same reason as above, (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL) also creates no output at compile time or load time.
<mrcom>
This is where I go "well, that sure sounds reasonable. Let's see if anybody else has some comments." Otherwise things just end with a thud real fast :)
<beach>
And the last form is quoted, so there is no output at compile time, nor at load time.
<beach>
"a thud"?
<mrcom>
The party fizzles out.
<beach>
Ah!
<mrcom>
So while we wait...
<beach>
Should I not have answered?
<mrcom>
,(when t `abc)
<ixelp>
(when t `abc) => ABC
<mrcom>
But that's quoted...
<mrcom>
No, no it's great you did.
<mrcom>
Gets things started.
mesuutt has quit [Ping timeout: 246 seconds]
amb007 has quit [Ping timeout: 268 seconds]
<mrcom>
And, more to the point, it clarifies things for me, which is the real, sneaky, reason for this.
amb007 has joined #commonlisp
<beach>
Oh, I saw through that from the start. :)
<beach>
Which is why I give an explanation to my answers and not just an answer.
<beach>
So at macro-expansion time, you will see the "whatever" printed and the "execute" because of what I said above about the EVAL-WHEN turning into a PROGN.
mesuutt has joined #commonlisp
<beach>
When a macro form (FOO ...) is compiled, it should depend on whether it is compiled by COMPILE-FILE or by EVAL or COMPILE.
rgherdt has joined #commonlisp
rogersm has joined #commonlisp
shka has quit [Quit: Konversation terminated!]
<mrcom>
All right, I'm getting tired of waiting... and you're completely right, none of the debug-io's print.
<beach>
If you invoke (FOO ...) at the REPL, in addition to what is printed at macro-expansion time, you will get only the :EXECUTE of the EVAL-WHEN, so a single GENERATED-compile-load-execute.
<mrcom>
To my simple mental model, it's as if DEFMETHOD is simply pulling apart a list, grabbing a name from it, and spitting out a different list.
<beach>
And you will get the GENERATED body.
<beach>
That is pretty much precisely what DEFMETHOD does.
<mrcom>
It's not looking inside the body, it doesn't even realize there are things you'd like it to do while it's chomping on the list.
<beach>
It does not examine the body forms.
<mrcom>
Er, defmacro, not defmethod.
<beach>
Oh.
danse-nr3 has joined #commonlisp
<beach>
Oh, yes. A macro is just a transformer of s-expressions.
shka has joined #commonlisp
<beach>
Now, if you don't do (foo ...) at the repl, and you stick (foo ...) in a file and compile it, then...
<beach>
What the file compiler sees after macro expansion is (progn (eval-when ...) (format...))
<kagevf>
younder: any examples of when your stringify comes in handy? just curious ...
<beach>
So the EVAL-WHEN is a top-level form. Then "compile-load-execute" is evaluated at compile time, load time, and execution time.
<beach>
So when you compile that file, you will see the messages from the macro expansion as above, plus "compile-load-execute".
<mrcom>
OOOh.. that's kind of the next question. What if we add "(defun baz0 () (foo "**baz0**"))" and "(baz0)". In other words, invoke the macro and run the result.
<beach>
The body of a DEFUN does not have top-level forms.
Krystof has joined #commonlisp
<beach>
So the (:compile-toplevel :load-toplevel :execute) will take into account only :execute.
<mrcom>
Yeah, I think you've already given an answer.
amb007 has joined #commonlisp
<beach>
OK.
<beach>
Anything still unclear?
<mrcom>
There's a little bit of a twist that might suprise some folks.
varjag has joined #commonlisp
<beach>
What's the twist?
<jackdaniel>
perhaps some nuance is lost on me but this discussion seems bizzare -- A: (question), B: (answer), A: (any other takers?)
<beach>
I think mrcom is trying to get multiple explanations that lead to the same final result.
<beach>
Just guessing of course.
<mrcom>
It's some things I found interesting. Not just "what happens" but "why it happens".
<mrcom>
OK, I just updated the pastebin.
<mrcom>
We see the "Foo-whatever", "Foo-execute" lines.
<mrcom>
But not "FOO-compile", or "Foo-load". And not the dashed line or "BAZ0-defun" or "-invoke".
<jackdaniel>
another bizzare thing is that this conversation /looks like/ mrcom is prompting a large language model ,) /me gets to his work
<jackdaniel>
gets back*
<beach>
mrcom: I explained why you don't see "compile" and "load".
<beach>
You should see the "defun" and "invoke" at load time.
<mrcom>
Quite right... missed that.
<beach>
mrcom: Think of the file compile as trying to transform the code into something that behaves essentially the same way as if you had loaded the source. Top-level forms are processed so that they will be executed when the FASL is loaded.
<beach>
*the file compiler
<beach>
So top-level FORMAT forms are not executed at compile time.
<beach>
Nor is (BAZ0) executed at compile time.
<beach>
(luckily because the function would not have been defined, as it is defined only when the FASL file is loaded)
<mrcom>
Fixed the pastebin.
<mrcom>
Good point.
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<beach>
Are you convinced about the answer to your last question in the paste?
<beach>
Those lines were discarded when the compiler compiled the macro FOO since the body form of the macro are not top-level forms.
<beach>
mrcom: It is not as though the compiled macro function contains EVAL-WHEN forms. It either contains the body of the EVAL-WHEN or it doesn't.
<mrcom>
That's a little off, I think. Hold on a sec...
rainthree has quit [Remote host closed the connection]
<mrcom>
I wasn't even thinking about the compile-vs-load aspect. It's a good thing to note.
<mrcom>
Updated the pastsebin again.
green__ has joined #commonlisp
green_ has joined #commonlisp
rainthree has joined #commonlisp
<beach>
But you kept the last question.
<mrcom>
Yes. That's not a question to me, its to whomever might read the paste.
<beach>
But I answered it.
<beach>
Oh, I see what you are saying.
<beach>
So we are done? No more explanations required?
<mrcom>
I guess so. Was going further, but nobody who's on right now seems to have any interest.
<mrcom>
Next step was to add (eval-when (:top-level-compile, -load, execute)) around the dashed lines and the defun's, and show more stuff is printing.
<mrcom>
Point being that top-level forms aren't evaluated (executed) by the compile by default, but can be with the right eval-when.
<beach>
Yes, that's the point of EVAL-WHEN.
<mrcom>
Then the really screwy parts, with certain combinations of eval-when options turning compile-time-too mode on and off.
<beach>
So for instance, the DEFUN macro might generate a compile-time form that stores information about the function that will be created at load time, so that when the compiler later on sees a call to that function, it can warn the user about incorrect number of arguments and such, and especially avoid a warning that the function is not defined.
<beach>
You will likely see such information generated if you macroexpand a DEFUN form.
<mrcom>
Exactly. The surprising thing to me is that DEFMACRO don't do that. It's totally oblviious to such efforts.
<beach>
Oh?
<mrcom>
Sort of.
<beach>
On the contrary, the macro has to be defined at compile time.
<beach>
So it should have (EVAL-WHEN (:COMPILE-TOPLEVEL ...) (setf (macro-function ...) ...)).
<beach>
Read the dictionary entry for DEFMACRO and you will see.
dino_tutter has joined #commonlisp
<beach>
"If a defmacro form appears as a top level form, the compiler must store the macro definition at compile time, so that occurrences of the macro later on in the file can be expanded correctly. Users must ensure that the body of the macro can be evaluated at compile time if it is referenced within the file being compiled."
<mrcom>
Yes, it does, but the point is that isn't executed by DEFMACRO. It only processes, it doesn't evaluate.
<beach>
I'm lost.
<beach>
Why would it execute the macro function if there is no macro call to it?
<mrcom>
Which is a point you internalized long ago, I suspect.
<beach>
I sure hope so.
<mrcom>
My mental model was more "this is just another function, whose output happens to replace the input form within the source."
<mrcom>
That's not exactly right.
<beach>
It is. And just as an ordinary function is not executed unless there is a call to it, the macro function is not executed unless there is a call to it.
rainthree has quit [Ping timeout: 255 seconds]
<mrcom>
The *generated* forms are not executed, correct. DEFMACRO itself executes when the compiler encounters (DEFMACRO foo...).
<beach>
*sigh*
<beach>
When the compiler encounters the DEFMACRO form, it macroexpands it and compiles the expanded form in its place. Nothing else.
<mrcom>
Yes. Exactly. Not how I was thinking of it.
<beach>
It is because the expanded form contains (eval-when (:compile-toplevel...) ..) that the macro function is created at compile time as well.
<mrcom>
Yes, that was clear.
<beach>
I absolutely need to get some work done now. Sorry to abandon you.
<mrcom>
No, no, appreciate your attention.
tok has joined #commonlisp
green__ has quit [Ping timeout: 260 seconds]
green_ has quit [Ping timeout: 260 seconds]
rogersm has quit [Remote host closed the connection]
rogersm has joined #commonlisp
rogersm has quit [Read error: Connection reset by peer]
rogersm has joined #commonlisp
rtypo has joined #commonlisp
shka has quit [Quit: Konversation terminated!]
shka has joined #commonlisp
awlygj has joined #commonlisp
mgl has joined #commonlisp
son0p has quit [Ping timeout: 252 seconds]
rogersm has quit [Remote host closed the connection]
rogersm has joined #commonlisp
rogersm has quit [Remote host closed the connection]
rogersm has joined #commonlisp
rogersm has quit [Remote host closed the connection]
rogersm has joined #commonlisp
attila_lendvai_ has joined #commonlisp
robin has joined #commonlisp
pranav has quit [Remote host closed the connection]
danse-nr3 has quit [Ping timeout: 268 seconds]
rogersm has quit [Ping timeout: 255 seconds]
shka has quit [Quit: Konversation terminated!]
danza has joined #commonlisp
uhuh has joined #commonlisp
danse-nr3 has joined #commonlisp
danza has quit [Ping timeout: 268 seconds]
attila_lendvai_ has quit [Ping timeout: 268 seconds]
shka has joined #commonlisp
mesuutt has quit [Ping timeout: 272 seconds]
msv has quit [Remote host closed the connection]
msv has joined #commonlisp
msv has quit [Remote host closed the connection]
msv has joined #commonlisp
phantomics_ has joined #commonlisp
phantomics has quit [Ping timeout: 268 seconds]
danse-nr3 has quit [Read error: Connection reset by peer]
random-jellyfish has quit [Ping timeout: 260 seconds]
mesuutt has joined #commonlisp
prokhor has joined #commonlisp
chomwitt has joined #commonlisp
green_ has joined #commonlisp
green__ has joined #commonlisp
decweb has joined #commonlisp
random-nick has joined #commonlisp
amb007 has quit [Ping timeout: 255 seconds]
chomwitt has quit [Ping timeout: 268 seconds]
prokhor_ has joined #commonlisp
prokhor has quit [Ping timeout: 268 seconds]
amb007 has joined #commonlisp
son0p has joined #commonlisp
Krystof has quit [Ping timeout: 268 seconds]
decweb has quit [Ping timeout: 255 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
mala has quit [Ping timeout: 252 seconds]
mala has joined #commonlisp
decweb has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 268 seconds]
Lord_of_Life has joined #commonlisp
yitzi has joined #commonlisp
attila_lendvai_ has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
danse-nr3 has quit [Ping timeout: 268 seconds]
amb007 has joined #commonlisp
kurfen_ has joined #commonlisp
chomwitt has joined #commonlisp
kurfen has quit [Ping timeout: 268 seconds]
amb007 has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
rainthree has joined #commonlisp
danse-nr3 has joined #commonlisp
green__ has quit [Ping timeout: 255 seconds]
green_ has quit [Ping timeout: 255 seconds]
green_ has joined #commonlisp
green__ has joined #commonlisp
Colleen has quit [Quit: Colleen]
Shinmera has quit [Quit: WeeChat 3.8]
ocra8 has quit [Quit: WeeChat 4.2.2]
Colleen has joined #commonlisp
Shinmera has joined #commonlisp
edgar-rfx has joined #commonlisp
rtypo has quit [Ping timeout: 268 seconds]
edgar-rft has quit [Ping timeout: 246 seconds]
anticomputer has quit [Quit: quit]
reb` has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
rtypo has joined #commonlisp
<mrcom>
OK, I'm still digesting mindshift macros-are-iterative-not-recursive-repeat-100-times, but have resovled the question about macros and top-level subforms.
<mrcom>
(To my satisfaction)
<mrcom>
chls 3.2.3.1
<mrcom>
Item 2. A top-level macro form. Its expansion is computed and processed as a top-level form.
<mrcom>
In the case of SBCL and CCL, where the expansion is something like (progn (eval-when ...) (eval-when ...)):
<mrcom>
Item 3. If the form is a progn form, each of its body forms is sequentially processed as a top-level form in the same proc mode (compile-time-too or not-compile-time).
<mrcom>
So item. 5, those top-level subforms are eval-when forms, where it gets complicated. For (eval-when :compile-toplevel :load-toplevel), it is processed as a top-level form.
<mrcom>
For (eval-when :compile-toplevel) alone, no :load-toplevel, it is *evaluated*, not processed.
<mrcom>
So, although spec says "standard macros can't evaluate into multiple top-level forms", and the commentary says "don't use (progn ...), use (let ...)"...
<mrcom>
Because of the particular combination of eval-when's, only one of the subforms can be considered to be a top-level form, at least during any particular compile/load phase.
<mrcom>
Sorry, "standard macros can't *process* into multiple top-levels".
<mrcom>
Language hair-splitting at its finest.
green_ has quit [Ping timeout: 255 seconds]
green__ has quit [Ping timeout: 268 seconds]
green_ has joined #commonlisp
<mrcom>
Although I suspect that was blindly ovbious what was meant to the implementers involved.
green_ has quit [Ping timeout: 252 seconds]
<bike>
i don't think "only one of the subforms can be considered to be a top-level form is correct
<bike>
*form" is correct
<bike>
i mean, both eval-when forms are top level, even if they're processed differently
edgar-rfx is now known as edgar-rft
<bike>
you can have a macro expand into (progn (eval-when (:compile-toplevel :load-toplevel) ...) (eval-when (:compile-toplevel :load-toplevel) ...)) just fine
<mrcom>
It's like of like (progn #+foo(xxx) #-foo(xxx)). Only one's going to happen. And the subforms *have* to be top-level, becuase they need the eval-whens to work.
<bike>
they both happen
<mrcom>
Yeah, but... like I said hair-splitting. TBH, I don't even know what the problem with multiple top-level sub-forms is.
<bike>
there isn't a problem
<bike>
is there like, some other context here?
<mrcom>
The standard says its forbidden for the standard-specified macros.
<bike>
i don't know what commentary is telling you not to use (progn ...), but it's pretty common to do so
<bike>
it's definitely not forbidden. where are you getting that from?
<mrcom>
3.2.3.1.2. Avoiding progn is just in the cleanup issue, not the standard, but the standard says "except where explicitly stated otherwise, no macro in the CL standard produces an expansion that could cause any of the suborms to be treated as top-level"
<mrcom>
The commentary says 'it's ok for users to do it, since they have control', "but users have no control over what the expansions of macros defined in the standard are...
<bike>
okay, well that means the subforms of the macro form. so for example it prohibits (defvar *foo* bar) from expanding in such a way that BAR is toplevel.
<mrcom>
The semantics of a macro call form can depend on whether or not its subforms appear at top-level"
<bike>
but it doesn't forbid macros from expanding into progns of other forms, and in practice many of them do.
Grauwolf has quit [Ping timeout: 240 seconds]
<mrcom>
"for example, (and <form>) could expand into (let () <form>), but not ... (progn <form>)"
Grauwolf has joined #commonlisp
<bike>
right, because then <form> is a subform of AND, i.e. something the programmer put in.
<bike>
but for a trivial example, (defun foo ...) will probably expand into something like (progn (setf (fdefinition 'foo) (lambda ...)) 'foo))
<mrcom>
No *that* I understand.
<bike>
both the SETF and the 'FOO are top level, and that's okay.
mgl has quit [Ping timeout: 260 seconds]
<mrcom>
s/No/Now/
edgar-rft has quit [Quit: don't waste your life by reading this]
edgar-rft has joined #commonlisp
josrr has joined #commonlisp
OlCe has joined #commonlisp
<mrcom>
Although it seems the writer of the commentary really meant "don't use (progn)". "Probably many implementations currently return macro expansions that violate these rules" and "It doesn't appear any of the ~90 macros in the standard require special exceptions."
mgl has joined #commonlisp
dlowe has joined #commonlisp
<mrcom>
But "'subforms' means user-supplied subforms, silly" seems to have won in practice.
chomwitt has quit [Ping timeout: 256 seconds]
aeth has quit [Ping timeout: 252 seconds]
<bike>
i really doubt they meant not to use progn at all. that would be ridiculous.
<mrcom>
Yeah, the more I think about it, the more it looks like everybody said "yeah, no". If the user puts "(and foo bar)", and that causes problems, well what do they expect?
<mrcom>
s/puts it as a top-level/
<bike>
no, that part is constrained. in that case FOO and BAR are not allowed to be top level.
<bike>
that is pretty clear from the standard and implementations actually do it.
<mrcom>
I'd think more appropriate is "don't suprise the user by grabbing some rando sub-form of theirs and promoting it to top-level"
<bike>
right, which is why that's what the standard says and what implementations do
aeth has joined #commonlisp
<mrcom>
Hm. See what you mean. SBCL and CCL implement AND as IF, and OR as (LET ...).
rtypo has quit [Quit: WeeChat 4.2.2]
<mrcom>
Although you really couldn't implement those w/ top-level subs.
<beach>
Only the ones with zero or one argument.
<mrcom>
Yeah, just about to say. SBCL does (THE T X). Cute.
<mrcom>
Oooh. ,(macroexpand-1 '(and x))
<mrcom>
,(macroexpand-1 '(and x))
<ixelp>
=> X; T
<mrcom>
Tsk tsk.
<beach>
I have never seen this rule before, so I probably don't respect it in the Common Macros library.
<mrcom>
Well, it's not progn
<beach>
I'll make a note to fix that.
<mrcom>
Yours are one of the 90 standard ones, are they?
<beach>
The library contains a bunch of macro definitions.
<mrcom>
Yeah, but the standard says its forbidden for the standards-specified ones. So technically you're good.
dlowe has quit [Remote host closed the connection]
dlowe has joined #commonlisp
<beach>
No, the library implements the standard ones.
<mrcom>
But again, who's going to do something like (and impossible-to-be-true (defun xxx)), and get suprised then it's optimized to a top-level defun.
<beach>
Still, I should fix it.
<mrcom>
I guess it's good to be that nit-picky in standards.
<ixelp>
Common-macros/Common-macro-definitions at master · robert-strandh/Common-macros · GitHub
yitzi has quit [Ping timeout: 268 seconds]
yitzi has joined #commonlisp
<mrcom>
Oh yeah, they're standard ones. Yeah.
<beach>
Yes, it's one of the libraries created as part of the SICL project.
luca_ has joined #commonlisp
rgherdt has quit [Ping timeout: 256 seconds]
luca_ is now known as OwlWizard
<ldb>
on CCL (macroexpand-1 '(and x)) => X
rgherdt has joined #commonlisp
<beach>
I think we just saw that.
<mrcom>
Yeah, that's what ixelp was showing.
<mrcom>
It's runnin on CCL.
smlckz_ has joined #commonlisp
<ldb>
ah, didn't catch that in the log
smlckz_ is now known as Guest759
Guest759 has quit [Changing host]
Guest759 has joined #commonlisp
<mrcom>
beach: I'm browsing through Common Macros... so you're deferring the normal side effects from DEFUN until something actually uses it?
<beach>
mrcom: No, I am inserting something determined by the client, because what it does at compile time depends on what the client wants.
eddof13 has joined #commonlisp
<ldb>
defer the compile time side effect to load time, to my understanding
Guest759 is now known as smlckz-
<beach>
I should hope not.
<beach>
If I do, then that's a mistake.
<beach>
The macro function calls a generic function to determine a form to insert as compile-time action, and the client must define a method on that generic function specialized to its CLIENT class.
<ldb>
well, now I see straight forward defun-compile-time-action, so it is supposed to do the compile time effect
<ldb>
but to my curiousity, how is `(defmacro defmacro' supposed to bootstrap?
<ixelp>
SICL/Code/New-boot/Phase-1/macro-programming.lisp at master · robert-strandh/SICL · GitHub
ocra8 has joined #commonlisp
mgl has quit [Ping timeout: 255 seconds]
<beach>
ldb: Let me remind myself how that works. It was a while since I worked on it.
<beach>
DEFMACRO is not CL:DEFMACRO because DEFMACRO is shadowed.
sailorCat has joined #commonlisp
<beach>
ldb: Sorry, I can't remember and I am too tired to figure it out right now.
sailorCa- has quit [Ping timeout: 252 seconds]
reb has joined #commonlisp
mgl has joined #commonlisp
eddof13 has quit [Quit: eddof13]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
dtman34 has joined #commonlisp
pfdietz has joined #commonlisp
mivanchev has joined #commonlisp
<mivanchev>
hey, could anyone help me debug why asdf is not finding a package I installed to /usr/share/common-lisp/source/fiveam ?
<Colleen>
mivanchev: scymtym said at 2024.03.26 11:40:22: in esrap rules, you can sometimes avoid :destructure + ignore like this (:destructure (one two three) (declare (ignore one three)) two) → (:function second) (:lambda (two) two) that is by "chaining" multiple rule options or even just (:function second) in this particular case which does not need a body
<mivanchev>
according to the docs this is where asdf looks per default
<mivanchev>
hmm, i think it's because of quicklisp's interference
eddof13 has joined #commonlisp
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
OwlWizard has quit [Quit: OwlWizard]
<beach>
ldb: In Low/utilities, there is a (CL:DEFMACRO DEFMACRO...). It defines the macro COMMON-MACRO-DEFINITIONS:DEFMACRO which expands to (cl:defmacro <mumble>) where <mumble> is a transformed name.
<mivanchev>
scymtym, many thanks with your esrap tools 2 months ago :)) I forgot to thank you
<mivanchev>
will implement it asap
<mivanchev>
I also want you to remind you of the new version for esrap ;))
<beach>
ldb: So (defmacro defmacro ...) will expand to (cl:defmacro common-macro-definitions:|defmacro| ...)
<ldb>
beach: ah, so the name is case sensitive, indicates there would be two definitions of defmacro in common-macro-definitions package
<beach>
Yes, I believe that's the case. I am still tired after a long day of work, but I am sure you can figure everything out from that file utilities.lisp.
<ldb>
thanks, I'll look from that file
<beach>
It's in Low/utilities.lisp
<beach>
ldb: Yes, I can confirm that both COMMON-MACRO-DEFINITIONS:DEFMACRO and COMMON-MACRO-DEFINITIONS:|defmacro| have macro functions associated with them, and they are not the same.
random-jellyfish has joined #commonlisp
<beach>
This is when the library is used extrinsically. I am not sure it is entirely prepared to work intrinsically.
<ldb>
there will also be a way out
<beach>
Definitely.
danse-nr3 has quit [Ping timeout: 268 seconds]
mesuutt has quit [Ping timeout: 260 seconds]
shka has quit [Quit: Konversation terminated!]
eddof13 has quit [Quit: eddof13]
shka has joined #commonlisp
green_ has joined #commonlisp
alcor has joined #commonlisp
mesuutt has joined #commonlisp
prokhor_ has quit [Ping timeout: 256 seconds]
wacki has joined #commonlisp
mesuutt has quit [Ping timeout: 256 seconds]
eddof13 has joined #commonlisp
X-Scale has quit [Quit: Client closed]
<scymtym>
mivanchev: right, i forgot. let me take another look
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
green_ has quit [Ping timeout: 256 seconds]
<mivanchev>
scymtym, regarding the ignore issue, maybe esrap could feature special naming for variables that need to be ignored
<mivanchev>
or maybe named patterns like in: (defrule property (and #\Tab (+ #\Tab) (capture identifier as id) ws #\= ws (capture rest-of-line as value))
<mivanchev>
or (bind vs (capture, and then (:bindings (id, value) ....
<mivanchev>
(bind rest-of-line :as value), something like that
prokhor has joined #commonlisp
<scymtym>
mivanchev: that's how i would design it as well (and have in https://github.com/scymtym/parser.packrat ) but that syntax wouldn't work easily with esrap's compilation model
<scymtym>
not to mention the sudden interface change
chomwitt has joined #commonlisp
<mivanchev>
¯\_(ツ)_/¯ it's how it is I guess
X-Scale has joined #commonlisp
yitzi has quit [Ping timeout: 256 seconds]
yitzi has joined #commonlisp
chomwitt has quit [Ping timeout: 246 seconds]
mivanchev has quit [Remote host closed the connection]
androclus has joined #commonlisp
mgl has quit [Ping timeout: 255 seconds]
Pixel_Outlaw has joined #commonlisp
pfdietz has quit [Ping timeout: 250 seconds]
luca_ has joined #commonlisp
luca_ is now known as OwlWizard
mesuutt has joined #commonlisp
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
amb007 has quit [Ping timeout: 264 seconds]
ldb has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
mesuutt has quit [Ping timeout: 256 seconds]
cage has joined #commonlisp
qhong has quit [Read error: Connection reset by peer]
bitspook has quit [Remote host closed the connection]
bitspook has joined #commonlisp
X-Scale38 has joined #commonlisp
X-Scale has quit [Killed (NickServ (GHOST command used by X-Scale38))]
X-Scale38 is now known as X-Scale
icebarf has quit [Read error: Connection reset by peer]
icebarf has joined #commonlisp
pfdietz has joined #commonlisp
jjnkn has joined #commonlisp
OwlWizard has quit [Quit: OwlWizard]
<bike>
The ELS 2024 schedule lists a paper titled "R7RS Large Status and Progress" but it doesn't appear to be in the proceedings. Does anybody know what happened or where I could get that paper?
mesuutt has joined #commonlisp
mesuutt has quit [Ping timeout: 252 seconds]
mgl has joined #commonlisp
pranav has quit [Remote host closed the connection]
smlckz- has quit [Read error: Connection reset by peer]
rainthree has quit [Ping timeout: 256 seconds]
wacki has quit [Ping timeout: 252 seconds]
mgl has quit [Ping timeout: 252 seconds]
wacki has joined #commonlisp
random-jellyfish has quit [Ping timeout: 252 seconds]
pranav has joined #commonlisp
mgl has joined #commonlisp
pranav has quit [Remote host closed the connection]
<jackdaniel>
bike: it was a presentation (not a paper)
<jackdaniel>
short summary what was r5rs, r7rs-small and r7rs-large, what is the scope /they want to/ implement
<bike>
i see. it said 'research paper' on the schedule
<jackdaniel>
yeah, I was a bit disappointed myself
<bike>
Thanks
<jackdaniel>
sure
<jackdaniel>
s/implement/cover/
ocra8 has quit [Quit: WeeChat 4.2.2]
mesuutt has joined #commonlisp
mesuutt has quit [Ping timeout: 240 seconds]
awlygj has quit [Quit: leaving]
yitzi has quit [Remote host closed the connection]
mesuutt has joined #commonlisp
mgl has quit [Ping timeout: 252 seconds]
mesuutt has quit [Ping timeout: 260 seconds]
pranav has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
pfdietz has quit [Ping timeout: 250 seconds]
amb007 has quit [Ping timeout: 255 seconds]
amb007 has joined #commonlisp
yottabyte has quit [Quit: Connection closed for inactivity]
jjnkn has quit [Remote host closed the connection]
tfeb has joined #commonlisp
tfeb has quit [Client Quit]
green_ has joined #commonlisp
cage has quit [Remote host closed the connection]
eddof13 has quit [Ping timeout: 268 seconds]
cage has joined #commonlisp
gorignak has joined #commonlisp
amb007 has quit [Ping timeout: 272 seconds]
amb007 has joined #commonlisp
ocra8 has joined #commonlisp
ldb has joined #commonlisp
<ldb>
things like hashtable
<bike>
what?
mgl has joined #commonlisp
<ldb>
r7rs-small left the hastable at large, thus someone asked me why scheme does not have hastable
<ldb>
it was there before r6rs
bitspook has quit [Ping timeout: 250 seconds]
<bike>
oh, this is in relation to r7rs-large. i see.
mgl has quit [Ping timeout: 268 seconds]
chomwitt has joined #commonlisp
waleee has joined #commonlisp
bitspook has joined #commonlisp
androclus has quit [Quit: Client closed]
trannus_aran has joined #commonlisp
bitspook has quit [Ping timeout: 250 seconds]
jmdaemon has joined #commonlisp
green__ has joined #commonlisp
ldb has quit [Ping timeout: 256 seconds]
green_ has quit [Ping timeout: 260 seconds]
ym has quit [Ping timeout: 246 seconds]
bitspook has joined #commonlisp
green__ has quit [Ping timeout: 260 seconds]
bitspook has quit [Ping timeout: 250 seconds]
cage has quit [Quit: rcirc on GNU Emacs 29.3]
cayley5 has quit [Quit: Ping timeout (120 seconds)]
pranav has quit [Read error: Connection reset by peer]
cayley5 has joined #commonlisp
trannus_aran has quit [Ping timeout: 250 seconds]
varjag has joined #commonlisp
pranav has joined #commonlisp
jmdaemon has quit [Ping timeout: 240 seconds]
bitspook has joined #commonlisp
cdegroot has quit [Ping timeout: 260 seconds]
bitspook has quit [Ping timeout: 250 seconds]
dlowe has quit [Ping timeout: 256 seconds]
androclus has joined #commonlisp
jonatack has quit [Ping timeout: 246 seconds]
mgl has joined #commonlisp
bitspook has joined #commonlisp
bitspook has quit [Ping timeout: 250 seconds]
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
wacki has joined #commonlisp
bitspook has joined #commonlisp
tok has quit [Remote host closed the connection]
wacki has quit [Ping timeout: 240 seconds]
bitspook has quit [Ping timeout: 250 seconds]
amb007 has quit [Ping timeout: 268 seconds]
jonatack has joined #commonlisp
chomwitt has quit [Ping timeout: 246 seconds]
jmdaemon has joined #commonlisp
bitspook has joined #commonlisp
bitspook has quit [Ping timeout: 250 seconds]
pve has quit [Quit: leaving]
shka has quit [Quit: Konversation terminated!]
attila_lendvai_ has quit [Ping timeout: 240 seconds]
wacki has joined #commonlisp
mariari has quit [Ping timeout: 256 seconds]
wacki has quit [Ping timeout: 264 seconds]
bitspook has joined #commonlisp
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
androclus has quit [Quit: Client closed]
bitspook has quit [Ping timeout: 250 seconds]
mgl has quit [Ping timeout: 268 seconds]
mariari has joined #commonlisp
pranav has quit [Remote host closed the connection]
bitspook has joined #commonlisp
bitspook has quit [Ping timeout: 250 seconds]
pranav has joined #commonlisp
wacki has joined #commonlisp
rgherdt has quit [Quit: Leaving]
wacki has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
bitspook has joined #commonlisp
varjag has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.2)]
bitspook has quit [Ping timeout: 250 seconds]
dino_tutter has quit [Ping timeout: 256 seconds]
jmdaemon has quit [Ping timeout: 256 seconds]
alcor has quit [Ping timeout: 240 seconds]
bitspook has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
wacki has joined #commonlisp
bitspook has quit [Ping timeout: 250 seconds]
wacki has quit [Ping timeout: 246 seconds]
bitspook has joined #commonlisp
bitspook has quit [Remote host closed the connection]