morganw has quit [Remote host closed the connection]
NotThatRPG has joined #commonlisp
<NotThatRPG>
Anyone know if it's possible to use the SBCL shebang with `/usr/bin/env` to find SBCL? Doesn't this run afoul of the limits on what can be put in a shebang line?
<Catie>
It should work fine for running it directly, I'm less sure about if you call it with like `sbcl --script file.lisp`
<ldb>
NotThatRPG: use #!/usr/bin/env -S sbcl --script
<NotThatRPG>
ldb: Thanks!
<ldb>
-S stands for seperate argument
<ldb>
so env won't try find a exe named "sbcl --script"
<NotThatRPG>
ldb: Thanks so much! that fixed my problem
NotThatRPG is now known as NotThatRPG_away
ldb has joined #commonlisp
Inline_ has joined #commonlisp
waleee has quit [Ping timeout: 260 seconds]
Inline__ has quit [Ping timeout: 268 seconds]
Inline__ has joined #commonlisp
Inline_ has quit [Ping timeout: 252 seconds]
azimut has quit [Ping timeout: 255 seconds]
ldb has quit [Remote host closed the connection]
Inline_ has joined #commonlisp
Inline__ has quit [Ping timeout: 252 seconds]
akoana has quit [Quit: leaving]
Inline__ has joined #commonlisp
Inline_ has quit [Ping timeout: 252 seconds]
waleee has joined #commonlisp
Inline_ has joined #commonlisp
Inline__ has quit [Ping timeout: 272 seconds]
Inline__ has joined #commonlisp
Inline_ has quit [Ping timeout: 272 seconds]
theBlack1ragon is now known as theBlackDragon
akonai has quit [Ping timeout: 256 seconds]
Inline_ has joined #commonlisp
bilegeek has joined #commonlisp
Inline__ has quit [Ping timeout: 272 seconds]
Inline__ has joined #commonlisp
akonai has joined #commonlisp
Inline_ has quit [Ping timeout: 272 seconds]
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
seletz has joined #commonlisp
Inline_ has joined #commonlisp
seletz has quit [Ping timeout: 268 seconds]
Inline__ has quit [Ping timeout: 272 seconds]
akonai has quit [Ping timeout: 252 seconds]
Inline__ has joined #commonlisp
Inline_ has quit [Ping timeout: 252 seconds]
akonai has joined #commonlisp
akonai has quit [Ping timeout: 272 seconds]
akonai has joined #commonlisp
<nij->
How hard is it to make a portable 1st class global env, that can be easily hooked into several implementations?
akonai has quit [Ping timeout: 268 seconds]
Inline_ has joined #commonlisp
Inline__ has quit [Ping timeout: 268 seconds]
Inline__ has joined #commonlisp
Inline_ has quit [Ping timeout: 252 seconds]
akonai has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
Inline_ has joined #commonlisp
Inline__ has quit [Ping timeout: 268 seconds]
Inline__ has joined #commonlisp
akonai has quit [Ping timeout: 252 seconds]
Inline_ has quit [Ping timeout: 256 seconds]
Inline__ has quit [Ping timeout: 256 seconds]
bilegeek has quit [Quit: Leaving]
akonai has joined #commonlisp
<jcowan>
nij-: Pretty much impossible to do it portably for mutable environments. R[67]RS provide `environment`, a procedure that converts a set of library imports into an immmutable environment.
<jcowan>
oh, sorry, I thought this was #lisp
<Bike>
how is immutability involved? i mean, it complicates things for lexical environments
akonai has quit [Ping timeout: 252 seconds]
<jcowan>
In Scheme, you import global bindings, not symbols. So if you import the binding of 'car to the car function, the compiler knows that 'car can't be mutated in the importing library (but can be mutated in the exporting library, though this is unusual)
akonai has joined #commonlisp
<jcowan>
Lexical enviroments aren't relevant to import/export.
waleee has quit [Remote host closed the connection]
Lycurgus has joined #commonlisp
waleee has joined #commonlisp
seletz has joined #commonlisp
<Bike>
this is true but does not seem related to implementing first class environments generally. that just means scheme made the choice to associate compiler information with some of its environments.
waleee has quit [Ping timeout: 252 seconds]
akonai has quit [Ping timeout: 260 seconds]
seletz has quit [Ping timeout: 252 seconds]
<beach>
nij-: As pjb pointed out in #clschool, implementing first-class global environments is relatively easy, though the paper explains how to do it without any performance penalties at run time in most cases.
<beach>
But in a typical Common Lisp implementation, access to THE global environment is hard wired and present in lots of places in the core code. You can't easily make such an implementation use first-class global environments instead.
akonai has joined #commonlisp
flip214 has quit [Remote host closed the connection]
mrcom has quit [Remote host closed the connection]
mrcom has joined #commonlisp
Lycurgus has quit [Quit: Exeunt: personae.ai-integration.biz]
akonai has quit [Ping timeout: 252 seconds]
akonai has joined #commonlisp
akonai has quit [Ping timeout: 265 seconds]
cercopith_ has quit [Remote host closed the connection]
cercopith_ has joined #commonlisp
<nij->
Even after the whole lisp is loaded? I wouldn't mind a 1st class global env after all the bootstrapping procedures (to start with).
<nij->
For that smaller goal, is it still not easy beach?
<beach>
Let me give you an example...
akonai has joined #commonlisp
<beach>
In a typical Common Lisp system, a function call such as (F ...) will be compiled to machine code that, given a symbol object representing F, will access the function slot in that symbol object using a single machine instruction.
thuna` has quit [Remote host closed the connection]
<beach>
You would have to go through every piece of already compiled code that makes function calls, and change every function call to use first-class global environments instead.
<beach>
You would probably have to do that at the machine-code level, since recompiling all the code is probably not possible, given bootstrapping constraints.
akonai has quit [Ping timeout: 255 seconds]
azimut has joined #commonlisp
<nij->
:(
<nij->
That seems unfeasible indeed.
<nij->
Then what are some other ways to load different versions of the same CL system?
<beach>
Did what I say make sense?
<nij->
I think so. I didn't think about the need of recompiling compiled function calls.
<beach>
But that's the very essence of compiled Common Lisp code. For performance reasons, the machine code has to be highly optimized and so it depends on all of the implementation strategies of the system.
<beach>
I don't know what it means to "load different versions of the same CL system".
<beach>
The compiler contains (directly or indirectly) information about those implementation strategies, so if you change any of those strategies, most likely the compiled code is obsolete and must be recreated.
akonai has joined #commonlisp
akonai has quit [Ping timeout: 252 seconds]
<beach>
nij-: In general, you can't just load the code of some Common Lisp system into a different Common Lisp system, nor probably into a running system of itself. We can do it with SICL code, because the SICL code uses first-class global environments, so it doesn't interfere with the host code.
<beach>
And with some careful considerations, it is possible to READ the code of a Common Lisp system into a different Common Lisp system, and then (cross) compile that code. This is what SBCL does for its bootstrapping. The way it does it (to avoid interfering with the host code) is that it uses temporary package names that are later changed.
<beach>
You can read the paper by Krystof (SBCL, a Sanely Bootstrappable Common Lisp) to see how this is done.
aartaka has joined #commonlisp
<nij->
I'm thinking of having a GUIX/NIX-like package manager, but dedicated for CL systems.
<nij->
However, if package B1 and B2 both depend on A, and if B1 depends on A:v1 while B depends on A:v2,
<nij->
s/package/system
<nij->
Currently without hacking the package names, there may be conflicts.
Inline has joined #commonlisp
<beach>
This is a new topic, right?
<nij->
Hmm I think they are the same topic, but yeah, it's safe to treat them as different ones.
<nij->
One line of thought is: 1st class global env -> version mixing -> GUIX-like CL system manager.
<beach>
Sure. First-class global environments make it possible to have a different version of a system in different first-class global environments.
<nij->
Yeah, now that a portable solution for that seems very unfeasible, I guess I need to start from something else that's easier..
<beach>
I am beginning to see the connection.
akonai has joined #commonlisp
<nij->
I imagine a guix like CL system manager has the potential to relieve zach from maintaining QL as a single man force.
Inline_ has joined #commonlisp
Inline has quit [Ping timeout: 252 seconds]
akonai has quit [Ping timeout: 252 seconds]
Inline__ has joined #commonlisp
akonai has joined #commonlisp
Inline_ has quit [Ping timeout: 268 seconds]
akonai has quit [Ping timeout: 255 seconds]
Inline_ has joined #commonlisp
Inline__ has quit [Ping timeout: 260 seconds]
azimut has quit [Ping timeout: 255 seconds]
rgherdt has joined #commonlisp
akonai has joined #commonlisp
Inline__ has joined #commonlisp
azimut has joined #commonlisp
Inline_ has quit [Ping timeout: 246 seconds]
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
Inline_ has joined #commonlisp
akonai has quit [Ping timeout: 246 seconds]
Inline__ has quit [Ping timeout: 272 seconds]
igemnace has joined #commonlisp
azimut has quit [Remote host closed the connection]
<Shinmera>
the solution to that problem is offering alternate dists that fulfill the same purpose.
akonai has quit [Ping timeout: 252 seconds]
pranavats has left #commonlisp [Error from remote client]
akonai has joined #commonlisp
<pve>
Good morning! If I do this to "pass a function" from one defmacro to another, will "symbol" be garbage collected (along with the function bound to it) sometime after macroexpansion of "test-2" is complete?
<beach>
dbotton: It gives you the entire form in a macro call.
<dbotton>
what does "entire form" mean
<pdietz>
It only makes sense in macro lambda lists, not ordinary lambda lists.
<pdietz>
The entire s-expression that was the macro form that's being macroexpanded.
<_death>
dbotton: often useful for compiler macros, that can return the form as-is when no transformation is implemented
<White_Flame>
in (defmacro foo (&whole whole) ...), (foo 1 2 3) will bind WHOLE to (FOO 1 2 3)
<jackdaniel>
say that you call the macro with-foo like this: (with-foo (xxx) "bam") and the macro with-foo has &whole xxx, then xxx will be bound to (with-foo (xxx) "bam")
<White_Flame>
in (defmacro foo (&whole whole ...) ...), (foo 1 2 3) will bind WHOLE to (FOO 1 2 3)
<dbotton>
so it is the form used to "call" the macro
<dbotton>
thanks!
<dbotton>
pdietz why would you say that it only makes sense in macro lambda lists?
<pdietz>
It's not allowed in ordinary lambda lists. See the CLHS.
<dbotton>
looking up, interesting cltl2e implies it works in all
<_death>
doubt that
<dbotton>
pg 208
<_death>
don't have a physical copy, unfortunately
<dbotton>
"these three markers are now allowed in other constructs as well"
<_death>
maybe give section
<dbotton>
8.1
<_death>
8 is a chapter titled Macros
<dbotton>
yes
<_death>
the "other constructs" means other than defmacro.. e.g., define-compiler-macro
<dbotton>
ok, I'll buy it
<jackdaniel>
what are they selling?
akonai has quit [Ping timeout: 272 seconds]
<_death>
it doesn't make sense for functions, because these don't deal with source code
<dbotton>
I could see use _death of a functioning seeing how it was called
<_death>
dbotton: that is a runtime property, for which you can get a backtrace from the implementation
<dbotton>
Well not saying I would do it when I can just write a macro :) just saying I can see use
<_death>
if you have (apply (car x) (cdr x)) do you really need to record that fact to pass that form to the function? that doesn't play well with compilation
<jackdaniel>
dbotton: you may define a macro (defmacro consing-call (operator &rest args) `(let ((*whole* '(,operator ,@args))) (,operator ,@args))) if you need it that badly
<jackdaniel>
then all you need is to do (consing-call apply (car x) (cdr x))
akonai has joined #commonlisp
<nij->
yitzi Yes, to keep multiple versions around in the same Lisp.
<beach>
nij-: In the same image, or just in a place that allows one of them to be loaded?
<yitzi>
nij-: have you looked at qlot?
anticomputer has quit [Remote host closed the connection]
gxt__ has quit [Write error: Connection reset by peer]
triffid has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
triffid has joined #commonlisp
<nij->
beach in the same image.
<nij->
yitzi Yes, I'm actually using qlot. But that doesn't allow loading different versions into the same-image.
gxt__ has joined #commonlisp
<nij->
It maintains different versions in the file system though.
<nij->
I was asking #Python how they solve this problem, but turns out that they don't and can't.
<nij->
CL's package, the possibility of 1st class global environment, and dynamic variables - all combined may be the only solution.
<nij->
When that day comes, I wonder if we can all rest and stop thinking about dependency problems.
<splittist>
Not having a solution perhaps limits the scope of the problem.
<nij->
splittist Could you elaborate?
<yitzi>
nij-: What actual real problem are you trying to solve?
<yitzi>
In other words, what dependency problem do you currently have?
<nij->
To have a CL system manager that minimizes human efforts for resolving dependency issues.
<nij->
I don't have. I just think that would be a great lift for the community.
<splittist>
But the community, such as it is, doesn't actually seem to have this problem in general. Does it?
<nij->
zach is working their a*s off every now and then, right?
<yitzi>
Yeah, I could be a minority opinion but I don't see the point. I don't really have dependency problems. I use environments like npm that attempt such solutions and they are terrible, IMHO.
<nij->
? I don't think I understand. You mean you don't see the point, but they are terrible?
<pjb>
nij-: Yes, we will be able to stop thinking about the dependency problem. Once our dependencies are specified as a set of specifications for a module, and modules are provided with their specification, and there's a system to automatically validate specifications, and possibly implement them when no matching dependency is found.
<pjb>
nij-: in short, no, never.
<nij->
"no, never" for what?
<pjb>
nij-: remember, even c6po, with his 6 million languages, can't interpret some alien stuff!
<Josh_2>
Can't say I've ever had a versioning issue
<nij->
Josh_2 Because zach resolve those for you?
<yitzi>
nij-: Both. I don't really have dependency problems in Lisp. In systems that have dependency issues and attempt to solve the problem like npm or guix I find the solution to just be bad.
<pjb>
Just implement everything yourself.
<Josh_2>
If I need to override a version in quicklisp I just use local-projects
<nij->
Oh I see yitzi. But that's also because zach has done us great favour, right?
<Josh_2>
I have done this a few times with postmodern
<Josh_2>
that is how you select the exact version you want
<nij->
Josh_2 When you overwrite with local-projects, isn't it risky that someother things you use don't like the versions you introduce?
<Josh_2>
Sure
<nij->
And in that case you have to overwrite that again.
<nij->
And again, if you're unlucky.
<nij->
Josh_2 yitzi I understand that we have little issues now, but much has to be contributed to zach.
<nij->
If we have a once-and-for-all solution to this, then why not?
<nij->
npm and python's conda stuff don't really solve the issue because they don't have CL's packages, I think.
<nij->
s/CL's packages/the concept of CL's package/
<nij->
beach, besides SICL, are there any CL implementation that supports 1st class global env?
<beach>
No.
<splittist>
What sort of a system is going to require multiple versions of postmodern? I know there are other language ecosystems where you start with 10^4 dependencies, but CL just isn't there. Do I wish someone would clone Xach and give each of them a private island in the Caribbean? Of course. But there are lots of things I worry about before these dependency issues.
<splittist>
That said, if you want to create a solution because it interests, you - please do! Just don't demand that I care. (Not saying you are, but...)
<_death>
in the end a programmer is responsible for his program's dependencies, whether they are direct or indirect
<Josh_2>
^
<nij->
splittist Yeah, I'm thinking and hoping a way without 1st class global env..
<nij->
If not, then perhaps I need to introduce that to SBCL. As a noob like me, it may take years before I get there.
<Josh_2>
When building your system keep in mind that quicklisp bumps versions :shrug:
<yitzi>
Any future improvements to CL system management should probably be built on top of CLPM, anyways.
<Josh_2>
In this respect the fact that many of the libraries in use are old and stable comes in handy :)
<nij->
yitzi Lemme look at CLPM.
<beach>
nij-: I seriously doubt that the maintainers of SBCL would accept such a contribution.
<nij->
yitzi Without being able to mix versions in the same Lisp image, how would such problem be resolved by CLPM?
son0p has joined #commonlisp
<nij->
beach :O ...
<nij->
I mean the day when I can actually write great code. Still no?
<Josh_2>
I dont see a need to mix versions... I have one library that has a v1 and a v2, v1 is not compatible with v2.
<Josh_2>
There is no need to mix
<nij->
If your lib gets used by many people one day,
<nij->
then there's a need.
<Josh_2>
Well 2 people is probably a lot in the CL community :joy:
<beach>
nij-: Still no. First-class global environments makes a call to FDEFINITION (or SYMBOL-FUNCTION) with a non-constant argument a bit slower, because it has to do a hash-table lookup. I think that's enough reason for it not being accepted.
<nij->
haha yeah, one side-effect of such lift is perhaps CL can grow without frictions.
<splittist>
the format of make files was not corrected at an early stage because it had 7 users
<nij->
Wait, beach, I remembering reading you mentioning this point in your paper, but "waived" it by saying that the mighty and fast sbcl is doing similar things anyway.
<nij->
:/ I hope that's not to mock me.. but I just read it yesterday. Perhaps I misunderstood your point..
<Josh_2>
_death: :joy:
<beach>
nij-: Not at all. I tend to forget things.
<nij->
"However, even in a high-performance imple- mentation such as SBCL, these values are not contained in symbol slots." page 3 of http://metamodular.com/SICL/environments.pdf
<beach>
What does "these values" refer to?
akonai has quit [Ping timeout: 260 seconds]
<beach>
Not to functions with names that are just symbols.
<jackdaniel>
symbol-value and symbol-function?
<beach>
nij-: I am guessing symbol values and perhaps functions with names like (SETF <symbol>).
ec has quit [Write error: Connection reset by peer]
anticomputer has quit [Remote host closed the connection]
<nij->
The at-run-time-evaluated arguments of FDEFINITION.
anticomputer has joined #commonlisp
<beach>
That makes no sense to me. Let me re-read...
ec has joined #commonlisp
<nij->
But really, Dependency Problem should go away in not just CL if there's no true and only one global env. We need to be able to switch env, and that's it.
<Bike>
what sbcl does there, i think, is bind names to internal funcallable objects called FDEFNs. when you redefine a function, the fdefn is mutated to have a new instance function, but it stays the same in the environment. so it's pretty similar to the sicl trick with a cons cell, i think, and might be compatible with first class environments. but i haven't thought about it.
<beach>
nij-: I don't understand that phrase myself anymore.
<beach>
Bike: Ah, I see. But I wonder whether that's what I was referring to.
seletz has quit [Ping timeout: 246 seconds]
<beach>
nij-: I am pretty sure there is a performance penalty, but, the purpose of SICL is not to maximize performance in all possible domains, and especially not for features that are less often used, and where the performance penalty is a small price to pay for better code structure.
<beach>
nij-: And I am not sure these trade-offs are the same for maintainers of other implementations.
<beach>
I may be wrong of course.
<nij->
I see. So while symmetric evaluation (meaning treating expressions and environments on equal-footing) can solve dependency issues, it may come with performance penalty that's non-resolvable.
ec has quit [Remote host closed the connection]
ec has joined #commonlisp
<nij->
This gets pretty involved then I thought. And since it doesn't seem to have been solved, I can think more about it.. Thanks for all the feedbacks!
<beach>
Sure.
<nij->
This conversation makes me appreciate SICL even more. Thanks for doing that.
<beach>
For what it's worth, I don't think the performance penalty is measurable in most applications. If I did, I would not have suggested first-class global environments.
<beach>
nij-: Great!
chrcav has quit [Quit: leaving]
<nij->
Bike Do you know who in #sbcl is really in charge of sbcl? It may be a long-term project for me, but I'm more motivated now to get into sbcl's internal.
<nij->
(Anyway, an obvious yet clear takeaway for me is that all dependency issues seem to root from the incapability of switching environments/contexts.)
<nij->
(E.g. conda, virtualenv, guix, and nix temporarily resolve that for *nix systems by providing an easier way to switch env/context robustly.)
<nij->
In that kind of *nix shell domain, it has been solved. But not yet in images internal to most computer programming languages.
<Josh_2>
Make a new lisp image
<Josh_2>
problem solved :joy:
<nij->
Then you want them to talk to each other Josh_2 at some moment.. which has the problem as the same sort of UNIX-like processes.
<nij->
Core problem being that structures are richer and easier to use than streams of characters/bytes.
<scymtym>
nij-: nobody is really in charge of SBCL. contributors come and go over the years and mostly work on areas they are interested in without too much coordination. the closest thing to a project leader is the release manager, Krystof
cercopith_ has quit [Remote host closed the connection]
cercopith_ has joined #commonlisp
akonai has joined #commonlisp
<nij->
Who is Krystof on github?
<nij->
scymtym Interesting. When a new change is introduced, are there criteria for it to pass (especially on performance)?
<mfiano>
csrhodes I think
<_death>
there used to be a guy 12 years ago writing some posts (a book?) about sbcl internals.. those posts are not totally up-to-date, but may be of interest.. I have local copies but seems even wayback machine can't find them nowdays (the blog was at insidelisp.blogspot.com) .. there was also https://github.com/guicho271828/sbcl-wiki/wiki
<ixelp>
Home · guicho271828/sbcl-wiki Wiki · GitHub
<mfiano>
_death: I would be interested in those local copies. The domain doesn't ring a bell
<scymtym>
nij-: there are no automated performance tests (anymore), as far as i know. but deliberate major or even minor performance regressions are unlikely to be accepted
<_death>
wonder why the author decided to remove them..
<nij->
scymtym What does "deliberate" mean here?
<nij->
I mean, any new feature has the risk of performance regressions, right?
<scymtym>
nij-: well, you can't reject changes because of performance regressions you don't know about. but the changes you are thinking about seem like they would introduce /known/ performance regressions
akonai has quit [Ping timeout: 252 seconds]
<jackdaniel>
just don't tell them about the regression ;)
jeosol has joined #commonlisp
<nij->
scymtym I see. So for that kind of obvious risk, in order for it to be merged, some extra convincing profiling report is required, right?
<scymtym>
nij-: i think a lot of convincing would be required, yes
<mfiano>
_death: Is there a reason there are 32 of 33 files (numbering starts at 2)?
<_death>
guessing it's just the way leafnode operates.. first message is notification that the group is subscribed
<mfiano>
AH ok. I'm not familiar with that service.
akonai has quit [Ping timeout: 268 seconds]
<mfiano>
I only ask because the first post (2) starts out as if there was previous content.
<_death>
leafnode is a local nntp server.. I use it so that gnus operates locally (fast)
<Josh_2>
What are these emails about?
<_death>
yeah, there may have been previous content, but I don't have it
<mfiano>
Wait
<mfiano>
I might be confused here. File "2" has a "Archived-at:" header pointing to chapter 22 of his blog.
<mfiano>
So I'm not sure which order to read these in :)
<_death>
mfiano: it's actually 2.2 but the dot got slugified out
<mfiano>
Ah makes sense
<mfiano>
Ok throwing these on my reading list. Thank you.
aartaka has quit [Ping timeout: 272 seconds]
aartaka has joined #commonlisp
nij- has joined #commonlisp
<mfiano>
_death: Do you still use Usenet and how big is your killfile? :) I think I gave up close to 20 years ago.
<_death>
well, there are a few messages on comp.lang.lisp every day or so.. but mostly I use it (leafnode, gnus) for gmane (mailing lists) and gwene (rss/atom, blogs)
<pdietz>
I gave up Usenet in 2007.
<Josh_2>
This is about sbcl internals?
<mfiano>
I am suddenly met with a nostalgic desire to try Usenet again. It's been decades. But I know setting that all up will probably result in a net loss.
akonai has joined #commonlisp
* mfiano
wonders how many of those few messages are legitimate.
<Josh_2>
I took at look at usenet not so long ago, there was a large amount of spam
<_death>
some trolls.. I did use gnus scorefile.. but a few years ago wised up and added filters at leafnode level.. that way I don't see "new messages" when there are actually 0 non-filtered ones
<mfiano>
That's not surprising. Browsing Usenet 20 years ago improperly was like browsing the web without an adblocker (or back then, but a bit later, a popup blocker)
<_death>
well, 20 years ago I read comp.lang.c++.moderated so there was no issue
Inline has joined #commonlisp
aartaka has quit [Ping timeout: 255 seconds]
akonai has quit [Ping timeout: 252 seconds]
<_death>
for comp.lang.lisp today I use eternal-september, which already filters much of the spam
<mfiano>
Back then I read very little CS stuff. Mostly fiction and table-top game stuff :)
<pjb>
usenet, but useful (in case if catastrophe, or in part of the world with low coverage (from starlink).
Krystof has joined #commonlisp
thuna` has joined #commonlisp
ttree has joined #commonlisp
Cymew has quit [Ping timeout: 272 seconds]
bitmapper has joined #commonlisp
azimut has joined #commonlisp
cercopith_ has quit [Ping timeout: 260 seconds]
cercopith has joined #commonlisp
nij- has quit [Ping timeout: 272 seconds]
doyougnu has joined #commonlisp
Inline_ has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
Inline has quit [Ping timeout: 252 seconds]
Inline__ has joined #commonlisp
rgherdt has quit [Ping timeout: 265 seconds]
Inline_ has quit [Ping timeout: 255 seconds]
akonai has joined #commonlisp
tane has quit [Quit: Leaving]
tane has joined #commonlisp
tane has quit [Changing host]
tane has joined #commonlisp
Inline__ has quit [Remote host closed the connection]
ym has quit [Ping timeout: 255 seconds]
rgherdt has joined #commonlisp
jeosol has quit [Quit: Client closed]
nij- has joined #commonlisp
doyougnu has quit [Ping timeout: 272 seconds]
nij- has quit [Remote host closed the connection]
Inline has joined #commonlisp
nij- has joined #commonlisp
pdietz has quit [Quit: Client closed]
aartaka has quit [Ping timeout: 256 seconds]
tyson2 has joined #commonlisp
aartaka has joined #commonlisp
Oddity has joined #commonlisp
aartaka has quit [Ping timeout: 272 seconds]
Krystof has quit [Ping timeout: 256 seconds]
Inline_ has joined #commonlisp
igemnace has quit [Remote host closed the connection]
<dbotton>
What is the difference between writing a compiler macro and placing a defmacro in an eval-when with :compile-toplevel ?
Inline has quit [Ping timeout: 252 seconds]
Inline_ is now known as Inline
<Bike>
you don't need to put defmacro in an eval-when. it has the same effect implicitly.
<Bike>
compiler macros are a different kind of thing from macros. macros are an essential part of your program semantics, i.e. there's no way for lisp to understand your code without knowing the macros you use. in contrast compiler macros are just optimization hints: you can put them on top of existing functions and macros, and lisp doesn't have to expand them if it doesn't want to
Krystof has joined #commonlisp
<dbotton>
If I only used :compile-toplevel wouldn't that in theory create the same thing a macro that only exists during compilation?
nij- has left #commonlisp [Using Circe, the loveliest of all IRC clients]
<dbotton>
Also is there something preventing using compiler macros in a way not intended (compiler hints)?
<yitzi>
Also, compiler macros share the same name as the function they shadow. And they can skip expansion by returning the original form.
<Bike>
oh, if you _only_ use compile toplevel then yeah, that will make the macro not available in the loaded code. but that's still a totally separate concern from being a compiler macro.
<Bike>
there is nothing preventing you from using compiler macros however you want other than the fact that lisp is allowed to totally ignore them.
cage has quit [Quit: rcirc on GNU Emacs 27.1]
<dbotton>
Yitzi compiler macros are required to shadow a function?
<Bike>
they can also shadow macros, but they basically shadow something, yes
<yitzi>
dbotton: Bike knows a lot more about those then me, but that is the intent. I don't know it is explicitly required in the spec.
<Bike>
well, "shadow" might not be the best term, since the original function/macro is still available
scymtym has quit [Ping timeout: 272 seconds]
<dbotton>
how do you choose which one evaluates?
Brucio-61 has quit [Ping timeout: 260 seconds]
<Bike>
you don't. lisp can decide to use the compiler macro or not.
<jackdaniel>
that's the trick - you don't. the compiler may ignore it
scymtym_ has quit [Ping timeout: 272 seconds]
<jackdaniel>
but you may construct your compiler macro to say "I refuse to expand that"
<Bike>
so if you want your code to make any sense, the compiler macro ought to expand into something that does what the underlying function/macro does
<jackdaniel>
i.e ETOOLITTLEINFO
<Bike>
taking us back to "they are just optimization hints"
<yitzi>
Like an optimization for + based on number of or type of arguments known at compile time.
<dbotton>
thanks, as none of this is obvious from cltl2e at all
<dbotton>
optimization for the compiler is a side note of potential use
<jackdaniel>
I wonder why are you so hooked on cltl2
<Bike>
cltl2 does not accurately describe the standard language, and compiler macros were added pretty late
<yitzi>
dbotton: ^
<Bike>
for example, compiler-macroexpand did not make it into the standard
<dbotton>
Reason is because it is there. I am adding notes etc and going through it
<dbotton>
I would not have known the differences and how far from standard in some areas had not have either.....
<dbotton>
which means many reading it (as I have been) not realizing it
<Bike>
the clhs is also there
<jackdaniel>
you may start with LISP 1.5, you'll have a more complete picture
waleee has joined #commonlisp
<yitzi>
Yeah, read CLHS first. Then CLTL2 as a curiosity.
<dbotton>
I read lisp 1.5
<dbotton>
Bike agreed clhs is there and something I refer to constantly but didn't approach is as a book
<_death>
well, cltl2 is a nice book, but you could also check the hyperspec as you go along.. sometimes it will clarify things (because the reality of CL implementations should reflect that)
<dbotton>
but I started doing the videos and 1/4 way through already of cltl2e so will likely finish it
inline_ has joined #commonlisp
<jackdaniel>
are there videos for cltl2?
<dbotton>
_death I do, sometimes is not clear
<dbotton>
yes I made already many
<jackdaniel>
ah, I thought that there were some old videos I didn't know about
<dbotton>
I have 5 on youtube and working on another 3 already
<_death>
for example I see cltl2 says a compiler is required to expand compiler macros.. but this later changed and 3.2.2.1.3 says it's not required
<jackdaniel>
I'm not sure whether promoting an obsolete non-standard is the best way to promote the language but oh well
<Bike>
i'm just saying, if cltl2 confuses you about something you should probably just check the clhs
<dbotton>
I do most cases and sometimes the language is same in both places
<dbotton>
like this question is not obvious in either
<dbotton>
nor my last one or two
<dbotton>
for example it only says - "The name can be a function name naming any function or macro." that does not sound like must by a shadow
<Bike>
really? did you check 3.2.2.1?
Inline has quit [Ping timeout: 272 seconds]
<dbotton>
no, I just looked up compiler-macro
<yitzi>
I says that it several places.
<dbotton>
I guess not realizing that there is a more book like section to clhs
Brucio-61 has joined #commonlisp
waleee has quit [Ping timeout: 260 seconds]
waleee has joined #commonlisp
<yitzi>
I haven't seen a statement that there must be a function/macro by that name yet, or a statement about exceptional situations. So I guess the expectation is that if the compiler macro passes on expansion then the usual exceptions for missing functions/macros apply.
<yitzi>
Bike: And 3.2.2.1.3 specifically calls it shadowing.
<dbotton>
From what I can see even here there is no requirement that a compiler-macro must be of an existing function or macro
<yitzi>
Err...maybe not.
<_death>
dbotton: there isn't (e.g., you can define a compiler macro before defining a function) but since the compiler may ignore it, it's not very useful
bilegeek has joined #commonlisp
Inline__ has joined #commonlisp
ym has joined #commonlisp
<_death>
indeed 3.2.2.1.2 mentions that compiler macro won't affect the result of fboundp.. this suggests that it's possible to define a compiler macro while the symbol is not yet fbound (and fboundp will still return false)
inline_ has quit [Ping timeout: 272 seconds]
<yitzi>
On SBCL defining a compiler macro for a non existent function is permitted and appears that fboundp is checked before the call to the compiler macro, hence the compiler macro is never called for a non-existent function.
_cymew_ has quit [Ping timeout: 252 seconds]
<_death>
yitzi: if I evaluate (define-compiler-macro foo (x) `(1+ ,x)) then I can (foo 42) in the repl and it returns 43
<_death>
but of course that's not guaranteed to happen
<yitzi>
Hmmmm....I did it with an empty lambda list and it didn't work. Let me check to make sure I did it right.
<yitzi>
_death: No, I did it wrong. You are correct. Apologies.
waleee has quit [Quit: WeeChat 3.7.1]
waleee has joined #commonlisp
pdietz has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
shka has quit [Ping timeout: 272 seconds]
Inline__ has quit [Quit: Leaving]
tyson2 has joined #commonlisp
NotThatRPG_away is now known as NotThatRPG
NotThatRPG is now known as NotThatRPG_away
triffid has quit [Ping timeout: 255 seconds]
triffid has joined #commonlisp
morganw has quit [Remote host closed the connection]
tane has quit [Quit: Leaving]
pve has quit [Quit: leaving]
bilegeek has quit [Remote host closed the connection]
bilegeek has joined #commonlisp
bilegeek_ has joined #commonlisp
bilegeek has quit [Ping timeout: 255 seconds]
ym has quit [Ping timeout: 272 seconds]
ym has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
marshmal has joined #commonlisp
marshmal is now known as elsa
azimut has quit [Ping timeout: 255 seconds]
azimut has joined #commonlisp
cercopith_ has joined #commonlisp
cercopith has quit [Ping timeout: 252 seconds]
bilegeek_ has quit [Remote host closed the connection]
bilegeek_ has joined #commonlisp
akoana has joined #commonlisp
cercopith__ has joined #commonlisp
<jcowan>
In my experience CLTL is better at explaining *why* than the hyperspec.
cercopith_ has quit [Ping timeout: 272 seconds]
bilegeek_ has quit [Remote host closed the connection]
bilegeek_ has joined #commonlisp
bilegeek_ has quit [Remote host closed the connection]
bilegeek_ has joined #commonlisp
rgherdt has quit [Remote host closed the connection]