Psybur has quit [Remote host closed the connection]
Nilby has joined #commonlisp
asarch has joined #commonlisp
taiju has joined #commonlisp
taiju has quit [Ping timeout: 252 seconds]
igemnace has joined #commonlisp
gioyik has quit [Ping timeout: 276 seconds]
tyson2 has quit [Remote host closed the connection]
taiju has joined #commonlisp
khrbt has quit [Ping timeout: 260 seconds]
khrbt has joined #commonlisp
karlosz has joined #commonlisp
Everything has quit [Quit: leaving]
brettgilio has quit [Quit: Leaving...]
brettgilio has joined #commonlisp
brettgilio has quit [Client Quit]
brettgilio has joined #commonlisp
karlosz has quit [Quit: karlosz]
waleee has quit [Ping timeout: 252 seconds]
molson_ has quit [Ping timeout: 250 seconds]
igemnace has quit [Ping timeout: 260 seconds]
char has quit [Ping timeout: 252 seconds]
igemnace has joined #commonlisp
prxq has quit [Ping timeout: 252 seconds]
prxq_ has joined #commonlisp
hendursaga has quit [Quit: hendursaga]
hendursaga has joined #commonlisp
<beach>
Good morning everyone!
<semz>
good morning
karlosz has joined #commonlisp
jemoka has joined #commonlisp
CrashTestDummy3 has joined #commonlisp
taiju has quit [Ping timeout: 265 seconds]
CrashTestDummy2 has quit [Ping timeout: 252 seconds]
taiju has joined #commonlisp
semz has quit [Ping timeout: 252 seconds]
char has joined #commonlisp
igemnace has quit [Quit: WeeChat 3.2.1]
igemnace has joined #commonlisp
semz has joined #commonlisp
CrashTestDummy2 has joined #commonlisp
igemnace has quit [Quit: WeeChat 3.2.1]
CrashTestDummy3 has quit [Ping timeout: 252 seconds]
gioyik has joined #commonlisp
gioyik has quit [Ping timeout: 276 seconds]
<lukego>
SLIME really needs a way to give you a hint when the long computation you're waiting for has stopped because SBCL ran out of heap space and discretely printed a nasty warning in *inferior-lisp* before waiting with the socket open at the ldb> prompt
karlosz has quit [Ping timeout: 252 seconds]
Nilby has quit [Ping timeout: 260 seconds]
jealousm` has joined #commonlisp
jealousmonk has quit [Ping timeout: 252 seconds]
asarch_ has joined #commonlisp
asarch has quit [Ping timeout: 252 seconds]
<beach>
lukego: SLIME is good, but it is not great, and some of the limitations are probably due to intrinsic problems with the technique being used.
taiju has quit [Ping timeout: 252 seconds]
taiju has joined #commonlisp
jealousm` has quit [Remote host closed the connection]
<lukego>
beach: True. But that sounds a bit like a fortune-cooking comment that could apply to any project :)
<lukego>
and in this case I'm not sure that it would be advantageous to have the tooling running inside that Lisp image that has run out of heap space (or e.g. heap corrupted) and landed at the LDB prompt. The fact that it's partitioned into a separate subprocess is kind of handy because I'm restarting the Lisp process multiple times per day but never losing my editor state, since my Emacs is a lot more stable than my Common Lisp :)
<lukego>
is the long term vision for mcclim ecosystem to run all of the Lisp code together in the same image? Or to partition it into multiple images e.g. the way HEMLOCK had REMOTE stuff to manage an "inferior" lisp process way back when?
<lukego>
This is btw the main topic on my mind this morning: where should the inter-process/inter-language boundaries in my system be? which parts are best integrated, which best separated, and which doesn't it matter? Interesting in the context of e.g. SMT solvers, machine learning toolkits, data visualization, etc, where the benefits of integration need to outweigh a *lot* of extra work reinventing stuff that's available separately
<beach>
Right, our Common Lisp implementations are not stable enough, or safe enough, to handle an IDE in the same image.
<beach>
But it seems like the wrong approach to take for granted that our Common Lisp implementations are not great, and work around it, rather than fixing the implementations.
Oladon has quit [Quit: Leaving.]
<beach>
I don't think that there is an agreed-upon vision for McCLIM. I know what I want, and I believe scymtym shares this vision. I also know that Shinmera (for example) does not share it. He once said something like "I will *never* use an editor that runs in the same image as my Common Lisp system".
<lukego>
My mental model of Lisp is also "I should restart the image at least once per day or week for the sake of hygeine" but I don't want ot restart my editor so often
<hayley>
My mental model of Lisp is that, would someone implement htop in CLOSOS for some reason, the machine should always have the exclamation mark that htop adds as a suffix to long uptimes.
<beach>
That is a weird model, but also probably due to restrictions of our Common Lisp implementations. Just as I don't restart my operating system even once a month, I think I shouldn't be required to restart my Common Lisp system. But the way things currently are, I pretty much have to.
<hayley>
"Uptime: 183 days(!), 01:51:23"
<beach>
lukego: Here is how I see it. A Common Lisp implementation should have multiple first-class global environments, and instead of restarting your entire system, you might be required to trash the current first-class global environment if you (say) delete an essential function, and create a new one.
<beach>
But then, that would not affect the editor.
gioyik has joined #commonlisp
gioyik has quit [Ping timeout: 276 seconds]
<lukego>
I already have that though? with global environments mapped onto unix processes.
<beach>
That's a bit different from what I am thinking.
<beach>
I am thinking a single address space.
<lukego>
I know. I see lots of benefits to the fully integrated approach, and lots of benefits to the full separated approach. I'm not sure if your model is a best-of or worst-of both worlds approach?
karlosz has joined #commonlisp
<beach>
Right, it's hard to tell. But I know of only one way to figure it out, namely to try it and see.
<lukego>
The expected reward isn't high enough for me, but that's a very uncertain quantity of course.
<beach>
Yes, our situations are very different.
<beach>
This vision I have has resulted in 2 papers per year for 8 years, and I can't think of a better line of research than that.
<lukego>
same same but different. I am just fully occupied tilting at my own windmills :)
<lukego>
but this topic is at the top of my mind right now. mapping out my own personal computing ecosystem in terms of lisp, C, R, Julia, python, etc. what to use for which tasks, and how to make them interact? I spend a lot of time bothering about this stuff -- and that's a very real cost that you don't have when you focus on a pure Lisp stack.
<lukego>
in the machine learning landscape it seems to me like some things benefit hugely from tight integration, e.g. quickly iterating gradient descent optimization over automatically-differentiated functions written directly in the application's language e.g. accessing internal data structures to guide the process. Julia has this via Flux.jl and Zygote.jl and people rave about it.
<lukego>
I was tempted to write my application in Julia to access that stuff but current feeling is that reinventing it in Lisp would be less work than (inevitably) reinventing lots of Lisp-isms that I would miss in Julia e.g. Emacs integrations.
<lukego>
On the other hand it seems like MCMC and neural network kind of stuff doesn't necessarily have much advantage of doing inside the application. they are like extremely special-case virtual machines that you configure and run but don't really do any interesting application-specific things inside (from what I can see.) a bit like SMT solving. Maybe that stuff should just get shelled out to an off-the-shelf solver in C++/Python/ec.
<lukego>
beach: btw I respect the work that you are doing and I recognize the dream, having had the same one a long time ago, but I'm just in a different corner of this gigantic expanding computing universe these days. I regret having these nay-saying interactions with you, but it seems rooted in your value judgements of e.g. Emacs based on your own subjective criteria, so I'm not sure how to refrain from reacting :)
<pjb>
In any case, eventually this should lead to the same user experience: if you botch an environment in your CL image, you will still kill it and start a new envionment…
<lukego>
(Maybe I should try harder to avoid naysaying. SICL does look like the foundation for future generations of Lispers from where I sit and that's hugely important. I'm just a bit more myopic and not often seeing much beyond a ~ 5 year time horizon.)
shka has joined #commonlisp
<beach>
lukego: You can be as much of a naysayer as you like. Like water off a duck's back to me.
<beach>
lukego: And I am not trying to convince you. What I write is for the benefit of all #commonlisp participants. Otherwise, I would do it in a private exchange with you.
gaqwas has joined #commonlisp
<lukego>
that's the thing, I don't like being a naysayer. I suppose that I feel baited. I'll take a break on that note :)
selwyn has quit [Remote host closed the connection]
selwyn has joined #commonlisp
igemnace has joined #commonlisp
cosimone has joined #commonlisp
khrbt has joined #commonlisp
kakuhen has quit [Quit: Leaving...]
dre has quit [Quit: Leaving]
CrashTestDummy3 has joined #commonlisp
CrashTestDummy2 has quit [Ping timeout: 252 seconds]
igemnace has quit [Quit: WeeChat 3.2.1]
dim has quit [Ping timeout: 252 seconds]
attila_lendvai has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
SAL9000 has quit [Quit: WeeChat 3.1]
SAL9000 has joined #commonlisp
<greyrat>
Lukego: I am migrating my Julia dev env from vscode to emacs, and I am quited pleased with eglot (whose non-REPL experience seems as good as vscode, or better for me since I can customize a lot of stuff in elisp) and Revise.jl (so that I can run a standalone REPL that automatically gets updated when I save my edits, i.e., an alternative to SLIME). (Not to mention, copy-pasting using evil text objects for 'cells' between '##' lines helps
<greyrat>
a lot with using a non-nitegrated REPL.) (jupyter-emacs and org-babel also used to work somewhat well, but recently have broken on my new emacs 28.)
<greyrat>
What I still haven't found is how to launch a graphical REPL without firing up the whole vscode Electron machinary, as the TUI REPL isn't as nice for working with plots and images.
<greyrat>
lukego: another thing I am working on, is to create a general purpose HTTP API using Jupyter kernels that can eval code in any languages. So for example, I'll load up Julia kernels with the needed dependencies, and then I can easily "shell out" to them in any language. This seems the easiest way to interop between different languages that sometimes have expensive startup costs, to me. What are your thoughts? (I currently have a
<greyrat>
self-implemented (not using Jupyter) HTTP API for zsh, and it has been perhaps the single most useful thing I have ever built. Using that, I can easily execute zsh code in, e.g., elisp, with a syntax as nice as `(z custom-zsh-function (elisp-functions-are-evaled-and-their-results-quoted) (identity some-elisp-var) automatically-quoted-string)`: `(z mkdir -p (identity my-path))` . I currently use some zsh helpers for running pipes (or
<greyrat>
directly use `(z eval 'produce | consume')`, but it's just a matter of doing the work to support `(z produce | consumer)` directly.
<greyrat>
(I have a lot of zsh code, so zsh takes ~6 seconds to boot up on my machine, which is my I don't just use `zsh -c '...'`. The same problem applies to Julia; Python starts up fast enough that I have not needed a server for it yet.)
random-nick has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
<hayley>
This is intentional and done to preserve modularity (good luck debugging a function which diddles other stack frames) and the possibility of compilation (to an extent).
<greyrat>
hayley: So it's completely impossible, and not just discouraged? :(
<greyrat>
I really like having stuff to shoot my own feet with. Beats not having a gun. ^_^
<hayley>
Yes. I wouldn't be frowning.
<hayley>
To be fair, I made up the former part, I don't know if it's true (though I suppose it is). But the latter part is a common argument for why you can't do such things.
<greyrat>
It's a pro-big-corporation argument IMHO
<seok->
hm, what does uiop/run-program:subprocess error mean ?
<hayley>
Dunno about that, myself and Gnuxie have written substantially about such things. It's plain unreasonable to expect everyone to implement such a feature to me.
<seok->
getting it on windows
tfeb has joined #commonlisp
tfeb has quit [Client Quit]
<greyrat>
seok-: Can you post a snippet that produces the error and is runnable by us?
<seok->
I'm trying to run clog, heard of it ?
<greyrat>
BTW, why not try it on the WSL first?
<seok->
trying to get it to work on portacle/windows
<greyrat>
No, I haven't heard of clog.
<greyrat>
If it has a linux version, do try it on WSL.
<seok->
it says he tested it on windows, maybe not on portacle
<seok->
run-program on portacle does cause issues
<hayley>
greyrat: The way I see things is that modular design makes individuals _more_ able to manage complex projects, and not less able. So corporations which want to make motivated individuals incapable of replicating corporate efforts would rather promote anti-modular concepts.
<greyrat>
hayley: Both approaches are valid, I do not say that non-modularity is somehow good. I am saying some places benefit from non-modularity. The costs of non-modularity can be much higher for corporations, and this coupled with their social elements of conservatism and conformity, produces the current world where big corporations are very bad positoned to use such non-modular, complex code. It's all about choosing the right tools for the
<greyrat>
requirements, and the differing requiremnts between indie, and big-tech work.
<greyrat>
seok-: No idea, if it's relevant to you, but Nyxt might be of interest. It doesn't even work well on macOS though, so you really want a Linux machine for this one.
<seok->
nyxt doesnt work on windows
<seok->
nyxt is a web browser though, clog is a web framework
<seok->
I have a linux machine just want to get this working on windows
<hayley>
On the contrary (again), big and established corporations can basically bail out bad design decisions. Whereas for mortals, such as myself, one would be wasting precious time trying to make it work.
<hayley>
Furthermore, such a situation is not fun, because I know I am wasting time.
<greyrat>
hayley: "bad design" is by definiton bad. I usually use such scoping hacks for well-behaved abstractions. Kind of like how Rust uses a lot of unsafe code in its internals, but presents a safe API to the user.
dre has joined #commonlisp
dre has quit [Client Quit]
<hayley>
Having written a smattering of unsafe performance hacks, that is still difficult to maintain.
<Xach>
greyrat: forbidding such things leads to better performance.
<greyrat>
xach: the best case scenario is to have different "dialects", ala racket, with different optimization needs and safety enforcement. "Glue" code that does not run in a hot loop can be very liberal with its (non)performativity.
phadthai has quit [Ping timeout: 250 seconds]
<Xach>
Sure - if you don't like how the language is defined, you can make one more to your liking.
<Xach>
Common Lisp isn't like that but isn't bad for making new languages.
<hayley>
I don't think Racket even has the capabilities for such bogosity, unless your language is almost entirely interpreted.
<Xach>
Right, write your own EVAL and anything goes.
<hayley>
Still, even if performance wasn't an issue, this is just a bad idea.
<Xach>
sometimes personal experience is the only way to really grasp something is a bad idea
gioyik has joined #commonlisp
<beach>
Wow, that is some very nasty code. I guess the fact that it is possible in Python explains the factor 50 performance penalty of Python over Common Lisp.
<Xach>
It reminds me of how the naive idea of "if I compile 'slow' language X to 'fast' language Y, my program will run faster" is false
<beach>
I mean, that such things are generally possible. Not that this particular possibility is responsible for it all.
gioyik has quit [Ping timeout: 276 seconds]
<beach>
Right, there are language-design decisions that can make it extremely hard to write a compiler that generates fast code.
<hayley>
It probably could be done efficiently if you tried hard enough (you could use debugging information to diddle call frames, but then you would have to handle every inferred type possible being violated), but it is still a bad idea.
<_death>
greyrat: one way to do that in a principled way is to pass a closure that sets the variable, (lambda (new-value) (setf my-var new-value)).. you can create a macro so that you write (setter my-var) instead
<beach>
hayley: But you would also have to prevent the compiler from deleting dead variables.
<hayley>
beach: Also true. Would it affect performance substantially? You could spill dead variables and be done with them.
<beach>
hayley: Not to bad in this case, as we decided the other day, but variables could also be replaced by strength reduction and such, so you would then have to keep them synchronized in loops.
<hayley>
Right.
<beach>
I think this question is another piece of evidence that it is a bad idea to let people without knowledge of compiler design make decisions about language design.
tyson2 has joined #commonlisp
<hayley>
With regards to being careful with unsafe code: from experience at best I find I need a piece of paper, in order to convince myself that my code works as intended. At worst, I keep finding mistakes (as I have been today, while testing regular expression compilation), which is not something you want to be doing for long.
<hayley>
Somewhere in the middle is using external automation tools. For example, with concurrent programs, I implement a model in TLA+ and wait a few minutes for it to check that the program won't break certain invariants. From what I read, the miri interpreter for Rust can do vaguely similar things for unsafe code.
Guest92 has joined #commonlisp
<hayley>
(The latter does not exhaustively check models, but it can detect races and mistakes in manual memory management. But, otherwise, you need tools outside the programming language to avoid problems that are usually not problems.)
Guest92 has left #commonlisp [#commonlisp]
rain3 has quit [Ping timeout: 240 seconds]
etiago has joined #commonlisp
Psybur has joined #commonlisp
igemnace has joined #commonlisp
Nilby has joined #commonlisp
Nilby has quit [Remote host closed the connection]
Nilby has joined #commonlisp
<attila_lendvai>
is there a swank backend for scheme, and more specifically guile?
jealousmonk has joined #commonlisp
<attila_lendvai>
hrm, there's at least contrib/swank-r6rs.scm
lisp123 has joined #commonlisp
Inline has quit [Quit: Leaving]
phadthai has joined #commonlisp
<random-nick>
there's an emacs package for interaction with scheme called geiser which is in some ways similar to slime
<random-nick>
though that doesn't have anything to do with common lisp
yewscion has joined #commonlisp
lottaquestions has joined #commonlisp
<pjb>
greyrat: you can, with closures.
<lucerne>
pjb: So to confirm my understanding; I'll create a clojure that sets the var in the parent scope, then I can pass this closure around, and anyone can set the aforementioned var?
<random-nick>
rich hickey already created clojure
<random-nick>
:^)
<lucerne>
oh yes :))
<lucerne>
(I have typed his lang much more than "closures" ^_^)
<beach>
lucerne: yes, but then there is no violation of modularity. The creator of the closure grants permission to modify the variable.
<beach>
And the compiler detects this situation, so does not optimize away the variable.
<beach>
So it does not correspond to the exact use case that greyrat wanted.
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
X-Scale` has joined #commonlisp
treflip has joined #commonlisp
treflip has quit [Remote host closed the connection]
<beach>
pjb: You went to a lot of trouble to make that work! :)
<_death>
at that point, just use specials..
<beach>
Right, it didn't occur to me that greyrat perhaps didn't know about special variables.
<beach>
But it seems plausible now. I mean, I guess Python doesn't have them?
lottaquestions has quit [Ping timeout: 252 seconds]
<_death>
it does not
<beach>
greyrat: Do you know about special variables?
<lucerne>
beach: IIRC, they are just dynamic vars?
<pjb>
lucerne: it's not awsome: we implemented C-like operators, so we get the same problems than in C. eg. cf. example foo* bar* in https://termbin.com/o8at
<beach>
lucerne: Yes, that's another name for them.
<lucerne>
beach: I guess what I want is local dynamic vars (the macro pjb has supplied seems exactly this?). I don't like polluting the global env with special vars.
<beach>
You don't have to "pollute" the global environment. Just declare the variable SPECIAL.
<pjb>
lucerne: if you want local dynamic variables, then just declare the variable special locally!
<lucerne>
How do I declare the variable special locally? :))
<beach>
(declare (special <var>))
<lucerne>
This would affect all mentions of this variable though?
<lucerne>
That's what I remember at least.
<Nilby>
I feel like lexical specials solve this issue.
<beach>
No, you have to declare it special in all places you want to refer to it.
<lucerne>
Nilby: What are lexical specials?
<beach>
lucerne: That's why it is not "polluting" the global environment.
<beach>
lucerne: There is no such thing as "lexical specials".
<pjb>
lucerne: it only affects mentions of this variable in the lexical scope of the special declaration.
<Nilby>
lucerne: ^ what pjb linked
<pjb>
special variables name dynamic variables that live in time, while lexical variable live in space.
<_death>
special variables have indefinite scope and dynamic extent
<Nilby>
I know beach won't approve of using the words "lexical special" because it's technically incorrect.
<lisp123>
pjb: special variables name dynamic variables that live in time, while lexical variable live in space. >>> best explanation I have heard yet
<lisp123>
Nilby: It's very incorrect, if you think about it a bit more :)
Inline has joined #commonlisp
<Nilby>
So what's the proper term? How does differentiate between a defvar and a (let (x) (declare (special x)) ...)
Mandus has quit [Ping timeout: 252 seconds]
<pjb>
greyrat: anyways, beach's comment means: Why do you want do that? It's a bad idea, don't do that!
<beach>
"local" would be a better adjective.
Mandus has joined #commonlisp
<pjb>
local is imprecise, it can be a textual (space) locality, or a temporal locality.
<_death>
Nilby: there isn't much of a difference.. defvar just declaims special
<pjb>
Nilby: defvar is eternal, while (let (x) (declare (special x)) ...) is temporary.
<pjb>
Nilby: define-symbol-macro is all-encompassing, while (let (x) ...) is a lexical scope.
<beach>
The difference is whether the variable is special in the global environment or not. Hence my suggested "local".
<pjb>
Yes, but lexical scopes can also be qualified of local. Hence the confusion.
<beach>
"non-global" would be an alternative.
<Nilby>
I understand how it works, I just want to use words that won't bother or confuse people.
<pjb>
Also, lexical scopes are not always contiguous, hence the notion of locality can be topologically strange. Similarly, temporary scopes (dynamic bindings) can be shadowed, and also, when threads are involved, can have strange topologies, since threads represent parallel times.
<lisp123>
Nilby: Have a think about what lexical means, hopefully that will help explain why that wording doesn't work
<_death>
since local declarations are used, I think "local special" would be ok
<pjb>
Notice the closing parenthesis between the two red areas.
<Nilby>
I do have a fondness for utilizing the thread topologies of "local" or "non-global" specials.
<Nilby>
lisp123: I don't like thinking. But, these variables are in fact introduced in a lexical scope, and then set somewhat but not totally free, by the declaration, so perhaps one should call them "free-lexicals".
Oladon has joined #commonlisp
tyson2 has joined #commonlisp
<lisp123>
I wouldn't do that since the meaning of lexical is most closely associated with the textual region - e.g. definition of lexical scope " Here references to the established entity can occur only within certain program portions that are lexically (that is, textually) contained within the establishing construct. "
<Nilby>
Of course one doesn't want to imply that they're free in time or space cost, which is the nearly the opposite.
<beach>
Why would you not use the word "special" to describe a restricted kind of special variable.
<beach>
?
<beach>
An adjective can be used to indicate such a restriction. But to use a completely different noun for it seems just so wrong.
<pjb>
Definitely. Special qualifies symbols naming dynamic variables.
igemnace has quit [Remote host closed the connection]
<pjb>
lisp123: true, but there's an operator that maps between time and space: it's eval (execution in general). The "text" in a lexical scope is evaluated "during" a time period. This is how dynamic environments come alive.
<Nilby>
I'll just say "local special" from now on. If beach approves, that's good enough for me.
<pjb>
I prefer temporarily special.
<pjb>
But granted a symbol that is locally declared special, let you name a dynamic variable temporarily.
<lisp123>
pjb: Makes sense, some though provoking ideas for sure
<pjb>
Note that the dynamic variable that is temporarily named depends on the dynamic scope: it can be an outer temporary dynamic variable, or the global dynamic variable.
<lisp123>
Adding (declare (special g)) gives an error here: (defun compose (f g) #'(lambda (x) (declare (special g)) (funcall f (funcall g x))))
<lisp123>
Any ideas why? Too much concepts for me to process in one go
yewscion has quit [Ping timeout: 250 seconds]
<lisp123>
Is it because g now has dynamic extent - is it disestablished after the function is defined?
<lucerne>
lisp123: I don't understand your function at all. Can you explain what it is supposed to do in plain English?
<Nilby>
It's a differnt g
<lucerne>
pjb: I looked at your examples of failure modes. Indeed, the solution really only works if the names of the original functions are also supplied as strings. And these special vars seem to be just a better fit. I had misremembered `declare special` as global like `defvar`.
brettgilio has quit [Quit: Leaving...]
<lucerne>
BTW, can one inspect the "stack" of a special variable? To see what value it has at the grandparent scope, for example.
<beach>
lisp123: See the phrase "special declarations can be either bound..."
<beach>
lisp123: Yours is a "free declaration" because it is not attached to the lambda-list variable G.
<lisp123>
beach: Its a bit confusing for me because there are references to both f & g within the funcalls
yewscion has quit [Ping timeout: 250 seconds]
<beach>
Why would you declare G special here?
<beach>
That seems to defeat the purpose of this function.
<lisp123>
Out of curiosity to see what would happen. From what I understand, f & g have indefinite extent (" The parameter bindings for f and g do not disappear because the returned function, when called, could still refer to those bindings."), so wanted to see what would happen if one adds in a special declaration which gives g dynamic extent? However, both you and Nilby say its a different G, but I can't seem to get my head around that
Mandus has quit [Ping timeout: 252 seconds]
<lisp123>
My theory was: is it (g) disestablished after the function is defined?
<pjb>
lisp123: your lambda is calling now a function that should be bound to a dynamic variable named g. The parameter of compose named g is a lexical variable!
<beach>
OK, slow down...
IlluminatedPileo has quit [Quit: You have been kicked for being idle]
<beach>
lisp123: Your SPECIAL declaration is not "attached to" the lambda-list variable G, because for that to be the case, it has to be first in the DEFUN body.
<pjb>
lisp123: if you declare it special: (defun compose (f g) (declare (special g)) #'(lambda (x) (declare (special g)) (funcall f (funcall g x)))) then the lambda will perhaps refer to the same dynamic variable that is now the parameter of compose, but since it's not called WHEN compose is evaluated, it won't be!
Mandus has joined #commonlisp
<beach>
lisp123: So it is a "free declaration", and it affects only references, as the Common Lisp HyperSpec page says. Not any binding like the lambda-list variable is.
<pjb>
lisp123: on the other hand, if you call the anonymous function returned by compose WHEN there is a dynamic variable named g defined that moment (= temporal scope), then then it will be able to call it.
<pjb>
lisp123: but since in general, random dynamic variables are unbound, you get this error.
<pjb>
lisp123: closures can only exist over lexical variables.
<pjb>
You can have a different tracer function depending on WHEN you call h.
<pjb>
If you call h in a loop, you can even change the *trace-composed-functions* binding in another thread (or in the body of the loop) >:-}~
cosimone has joined #commonlisp
<lisp123>
Special variables are free as in freedom, there is not controlling them!
<lisp123>
This example I get pretty well
<lisp123>
Nilby: How long have you been programming in Lisp?
<Nilby>
lisp123: I was first exposed to lisp around the age of 10, and I am very old. I only stopped using other languages about 16 years ago.
<lisp123>
Nilby: Wow nice :)
<Nilby>
lisp123: My dad thought it would stop me from getting in trouble to put me in front of a teletype at MIT. He was very wrong.
<lisp123>
beach &
<lisp123>
Nilby: :) Very lucky to have been at MIT!
attila_lendvai has quit [Ping timeout: 250 seconds]
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
<Nilby>
lisp123: In my case it didn't matter since I was born with a severe allergy to academia. It mearly gave me a warped and mostly incorrect ideas about robots, programming languauges, and the future.
cosimone has quit [Ping timeout: 250 seconds]
<lisp123>
Nilby: I see, must have been a lot of hype as well back then
<lisp123>
(in AI and other stuff - hence AI Winter)
<Nilby>
exactly
<etimmons>
borodust: I noticed that in CLAW repos you like to include the foreign lib's repo as a submodule. Have you messed around at all with having ASDF build the foreign lib for you?
<borodust>
etimmons: i do link foreign lib repos in wrapper projects and primary reason is to have specific version of headers
<borodust>
etimmons: i'm totally not into idea of building foreign libraries from asdf ;p
<borodust>
etimmons: it's hard to get things goind in native way across different platorms (different knobs needed to be triggered to build properly), implementing that in asdf feels like being a total nightmare
<etimmons>
borodust: That's fair! Kind of just wondering how you ensure the header version matches the lib version if you use the system's lib
lisp123 has quit [Remote host closed the connection]
<borodust>
etimmons: btw, also when putting bindings into a quicklisp dist i strip everything foreign - no headers, no c/c++ code, no foreign project as a whole
<borodust>
meaning user won't be able to build foreign library at all by using system from a dist at all
<borodust>
etimmons: i ensure that by using bodge-blobs-support system
<borodust>
i keep prebuilt libraries as a separate system