<odddy>
I think in English and write in portugues, sorry hahaha
<bjorkintosh>
I understood what you meant.
<bjorkintosh>
you'll get up to speed very quickly with Practical Common Lisp.
<odddy>
I thought I'd start with the one I mentioned, because it goes from the basics to problem solving, because that's why I chose Lisp, day to day I work with Go but I have a lot of trouble thinking of solutions, you know?
<bjorkintosh>
indeed. both are very good options.
<bjorkintosh>
but problem solving comes with experience.
random-nick has quit [Ping timeout: 268 seconds]
randm has quit [Remote host closed the connection]
randm has joined #commonlisp
semz has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
decweb has quit [Quit: Konversation terminated!]
<zablozki>
gentle introduction is a great intro book!
semz has joined #commonlisp
istewart has joined #commonlisp
NotThatRPG has joined #commonlisp
odddy has quit [Quit: Client closed]
<veqq>
odddy: https://lem-project.github.io/ is easier than emacs, is written in common lisp (so doing fancy stuff later is easier) and requires 0 set up
<ixelp>
Lem
smlckz- has joined #commonlisp
smlckz- has quit [Changing host]
smlckz- has joined #commonlisp
istewart has quit [Quit: Konversation terminated!]
manwithluck has quit [Remote host closed the connection]
manwithluck has joined #commonlisp
Catie` has joined #commonlisp
Catie has quit [Ping timeout: 260 seconds]
weeks has quit [Remote host closed the connection]
edgar-rft` has joined #commonlisp
istewart has quit [Quit: Konversation terminated!]
edgar-rft has quit [Ping timeout: 260 seconds]
skeemer has quit [Ping timeout: 248 seconds]
zwr has quit [Read error: Connection reset by peer]
zwr has joined #commonlisp
pve has joined #commonlisp
shka has joined #commonlisp
Guest47 has joined #commonlisp
DustyDynamite has joined #commonlisp
DustyDynamite has quit [Client Quit]
DustyDynamite has joined #commonlisp
Cymew has joined #commonlisp
bpanthi977 has quit [Ping timeout: 245 seconds]
<veqq>
odddy: search for "irc client". The client will connect to libera.chat There is no special or specific client, but literally hundreds. I use thunderbird.
mishoo has joined #commonlisp
<aeth>
Usually people either use an in-terminal IRC client (inside of tmux or screen) or put it behind a "bouncer" relay to persist their sessions.
<aeth>
(In the '90s/'00s there was an expectation of people being offline, but not anymore...)
ingeniot has joined #commonlisp
ingeniot has quit [Client Quit]
rgherdt has joined #commonlisp
skeemer has joined #commonlisp
ingeniot has joined #commonlisp
masinter_ has joined #commonlisp
pok_ has joined #commonlisp
ello- has joined #commonlisp
jistr_ has joined #commonlisp
thonkpod_ has joined #commonlisp
zagura_ has joined #commonlisp
cross_ has joined #commonlisp
masinter has quit [Ping timeout: 260 seconds]
mange has quit [Ping timeout: 260 seconds]
pok has quit [Ping timeout: 260 seconds]
cross has quit [Ping timeout: 260 seconds]
thonkpod has quit [Ping timeout: 260 seconds]
Cymew has quit [Ping timeout: 260 seconds]
zagura has quit [Ping timeout: 260 seconds]
ello has quit [Ping timeout: 260 seconds]
jistr has quit [Ping timeout: 260 seconds]
masinter_ is now known as masinter
pok_ is now known as pok
pok has quit [Changing host]
pok has joined #commonlisp
ingeniot has quit [Quit: ingeniot]
ingeniot has joined #commonlisp
chomwitt has joined #commonlisp
mgl has joined #commonlisp
Guest47_ has joined #commonlisp
skeemer has quit [Ping timeout: 252 seconds]
Guest47 has quit [Remote host closed the connection]
prb has joined #commonlisp
DustyDynamite has quit [Quit: Leaving]
weeks has joined #commonlisp
kagevf has quit [Ping timeout: 276 seconds]
<mgl>
So, the issue yesterday with LOAD-TIME-VALUE on CLISP was not so much the order, but the fact that CLISP seems to optimize away the L-T-V form entirely if its return value is not used, and in my case it's for the side effect only. The workaround is easy, but is this legal behaviour?
<beach>
I am not so sure that what CLISP does is conforming behavior. Maybe I am missing something.
rtypo has joined #commonlisp
notzmv has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 248 seconds]
Lord_of_Life_ is now known as Lord_of_Life
LainIwakura has joined #commonlisp
veqq has quit [Ping timeout: 268 seconds]
zagura_ is now known as zagura
zos has joined #commonlisp
<beach>
There is nothing in the dictionary entry of LOAD-TIME-VALUE that suggests that it can be eliminated if the resulting value is not used.
<gilberth>
There's nothing that says otherwise. It is said that it is evaluated "only once" during loading. And often this means "not more than once".
<beach>
Wow!
<gilberth>
What?
<Alfr>
gilberth, but there's also a "but arranges for the execution of form to occur at load time".
<gilberth>
Alfr: True. Would I want to defend CLISP I'd say the intent of that phrase is to say "at load time, not at any other time."
<gilberth>
"Not at compile time, not at macro expansion time, but at load time it shall ever evaluate."
<gilberth>
LOAD-TIME-VALUE is clearly meant for literals not for effect. So I'd argue that CLISP's interpretation is reasonable.
ingeniot has quit [Ping timeout: 276 seconds]
notzmv has quit [Ping timeout: 248 seconds]
<gilberth>
ACL shares CLISP's interpretation.
<Alfr>
So, something occurs (at load-time) doesn't imply that this something actually happens?
<gilberth>
Alfr: Not always. "Cars drive on roads". Does imply that every road is driven on by a car.
<gilberth>
.oO(Is that even English?) /me shrugs.
LainIwakura has quit [Ping timeout: 240 seconds]
<gilberth>
* Does it imply ... ?
<jackdaniel>
over here even every sidewalk is driven on by a car, so yeah, theoretically it does not, but in practice... :)
<beach>
Maybe we should then also allow for (SETQ <var> <form>) to be eliminated if <var> is not used after this form.
<jackdaniel>
variables have indefinite extent
<gilberth>
I would expect every compiler doing that. If the variable isn't used at all there shouldn't be any.
<jackdaniel>
special variables that is
<jackdaniel>
s/special/dynamic/
<jackdaniel>
sigh
<gilberth>
If the compiler can prove that the special variable can't ever be read, that too.
<jackdaniel>
that leads to an optimization nonsense so frequently pointed out in C compilers
<aeth>
At the REPL? With e.g. :: even. I guess if you give it a gensym name?
<aeth>
Assuming global
<jackdaniel>
can I prove that it is UBI? then let's rehash whole functions even /before/ that statement
<jackdaniel>
UB *
<aeth>
undefined behavior investigation
<gilberth>
jackdaniel: Apart that it would probably not be worth the effort to do escape analysis with symbols, can you observe the difference between (macrolet ((foo (&aux (g (gensym))) `(let (,g) (declare (special ,g)) (setq ,g 42) nil))) (foo)) and 'nil ?
<jackdaniel>
I can observe a difference between (setq ,g (something-with-side-effects)) though
<jackdaniel>
I'm not saying that optimizing code and removing dead code doesn't make sense
<gilberth>
Sure. I though it was about the setting being eliminated. Of course you can't eliminate the function call itself unless you can prove that it has no side effects at all.
<gilberth>
Back to the original question about LOAD-TIME-VALUE. I just wanted to point out that CLISP's and ACL's interpretations are reasonable interpretations. Especially so as the intent of LOAD-TIME-VALUE is about having literals and not about the side effect.
<gilberth>
So for all practical purpose I would just accept that this interpretation exists and arrange it so that the LOAD-TIME-VALUE cannot be optimized away. Or just do whatever needs to be done with a top-level form proper.
<gilberth>
I mean, you can't depend on the order in which LOAD-TIME-VALUE forms are evaluated in the first place. So you can't be sure exactly when that side effect takes place during loading.
zos has quit [Remote host closed the connection]
zos has joined #commonlisp
<beach>
gilberth: Why can't you remove the evaluation of the form if the variable is no longer used? It would be consistent with what you said before.
<beach>
gilberth: It said that the form is evaluated, but like the cars, that doesn't mean it is always evaluated all the time according to you. And the page doesn't say that the evaluation of the form can't be omitted when the variable is not used, so that would mean, according to you, that it is a valid thing to do.
<gilberth>
beach: Are we talking about (SETQ ,(gensym) (MAKE-LOAD-FORM ,something))? Then yes, with my interpretation you can, if you wish.
<ixelp>
(gensym) => #:G1
<gilberth>
ixelp: Bad bot.
<beach>
gilberth: No, I am talking about (let ((x nil)) (setq x (print ...)))
<beach>
gilberth: I see no difference between your reasoning about LOAD-TIME-VALUE and elimintaing the (PRINT...).
<gilberth>
beach: Then of course it can't be eliminated.
<beach>
According to your reasoning about LOAD-TIME-VALUE, it can.
<gilberth>
beach: The difference is in the interpretation of "only once". I say that Bruno's take to read that at "not more than once" is reasonable. You appear to read that as "exactly once".
<beach>
If "only once" means "not more than once", then "is evaluated" must mean "might or might not be evaluated" since "cars drive on streets" means that a particular car might or might not drive on the street.
<gilberth>
As with my interpretation LOAD-TIME-VALUE doesn't make the promise that the form is evaluated at all. It says "only once" and I read it (on Bruno's behalf) as "not more than once". Which might be the intent of the authors.
<gilberth>
beach: Yes.
<beach>
And I think you are reading it totally wrong.
<gilberth>
Why didn't they write "exactly once" then?
<beach>
gilberth: Seriously? Do you want me to read the standard and figure out where "exactly" was omitted even though that is what the text means?
<gilberth>
Does the sentence: "You may take this exam only once." imply that I am obligated to take it?
<beach>
I really don't care to discuss analogies about cars or exams.
<gilberth>
We're discussing English language don't we?
<beach>
Not me.
<jackdaniel>
load-time-value is specified to delay evaluation of form, not to "create literals"
<beach>
And I am through with this discussion, because it is not good for my blood pressure.
<gilberth>
jackdaniel: Then it would be called LOAD-TIME-EVAL :-p But, yes, that is also a reasonable guess at the intent.
<jackdaniel>
it was first proposed to be called LOAD-TIME-EVAL (haha)
<gilberth>
Wow!
<jackdaniel>
and they suggest, that if we really want to eval (in this non-normative text), it is suggested (LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
<jackdaniel>
check mate, time for a coffee :)
<jackdaniel>
(but I don't really care, so feel free to disagree - in practice some popular implementations have this other interpretation, so the code should be wary anyway)
<gilberth>
I don't particularly care either and accept Bruno's and Franz' interpretation and would make use of LOAD-TIME-VALUE accordingly.
<|3b|>
from 3.2.2.2 "the compiler arranges for it to be evaluated at load time. "
<gilberth>
|3b|: Alfr noted that already. With Bruno's and Franz' hat on I could say it's about saying that it's load time and not compile time or macro expansion time. Not about that it must happen.
Guest47 has joined #commonlisp
<|3b|>
that seems pretty clear to me that it should be evaluated during LOAD
<Alfr>
I was alluding that "to occur" actually implies that something actually "happens".
<gilberth>
Hmm.
<|3b|>
and like PRINT, you can only skip things if you can prove they have no side effects
<|3b|>
(can you skip PRINT if you know the stream is an empty broadcast stream?)
<gilberth>
Sure. The question is whether a LOAD-TIME-VALUE must be evaluated no matter if the value is every used.
<Alfr>
gilberth, though, if the implementation can prove that evaluation does not have "observable" consequences, I guess it then still may apply DCE as usual.
<gilberth>
Alfr: A compiler can always do that, that's not the question. E.g. you don't expect that #'+ really is called when comping (+ 1 2).
<gilberth>
* compiling
<|3b|>
would you read "are evaluated only when the resulting compiled file is loaded" to mean you can skip them?
<gilberth>
No. I won't interpret this as saying "does not need to be evaluated if not used." This sentence is about that evaluation happens at load time, not compile time, not macro expansion time, not read time.
<gilberth>
Anyhow, I'll leave the discussion and just take away that there are different interpretations.
<jackdaniel>
gilberth: "But, yes, that is also a reasonable guess at the intent." -- no, " load-time-value provides a mechanism for delaying evaluation of form until the expression is in the run-time environment; see Section 3.2 (Compilation). " is literally the first sentence of the description (normative) of the operator
<|3b|>
jackdaniel: nah, that doesn't work as well
<|3b|>
with that you could defer it until you actually use the value
<jackdaniel>
|3b|: what I mean is that what I've said earlier was not an "interpretation" but a "quote"
<|3b|>
ah
* |3b|
wonders when clisp/acl evaluate the forms if the value is used
<jackdaniel>
|3b|: "the evaluation of form will take place only once when the file is loaded" narrows it a lot
<sixfourtwelve>
Hey guys, I've lost a bit of the chat history, but does anyone happen to know the other irc channel that's for beginner common lisp? I remember it have the word "school" in it
<|3b|>
right, i agree it should happen during LOAD, but since they don't do that for unused values, i wonder if they do for used values
<|3b|>
or if they delay everything until use instead of load
<jackdaniel>
sixfourtwelve: #clschool
<gilberth>
Yes, CLISP and ACL evaluate it during loading.
<sixfourtwelve>
jackdaniel: That's great, cheers!
<jackdaniel>
delaying until use would be strictly violating the spec I think (if we even bend our understanding to gilberth's interpretation (on behalf of Bruno))
<jackdaniel>
even if we bend*
<gilberth>
Yes, it would.
<mgl>
I think the authors of the standard implicitly assumed the L-T-V forms are side-effect free.
<mgl>
"If the same list (load-time-value form) is evaluated or compiled more than once, it is implementation-dependent whether form is evaluated only once or is evaluated more than once."
<jackdaniel>
mgl: read into issues that outline the intent
<jackdaniel>
(I've linked them earlier)
<jackdaniel>
even this passage is discussed to some length
<jackdaniel>
s/length/extent/
<gilberth>
Hmm. What about a file saying (defun foo () (load-time-value (bar))) (defun bar () (load-time-value (foo))) ?
<jackdaniel>
and what about a file saying (defun foo () (bar)) (defun bar () (foo)) ?
<jackdaniel>
or simply (loop) ?
<jackdaniel>
motion your honour: remove loop and defun from the standard
<gilberth>
What I was after was that (and I never looked into how LOAD-TIME-VALUE is implemented) they probably must be some on-demand behind it. Suppose in FOO and BAR this is somehow guarded by some IF the compiler can't tell which way it goes.
<jackdaniel>
I'm currently working hard to put locals in bytecodes compiler in ecl on the stack
<ixelp>
mgl-pax/src/base/pax.lisp at 863cb147e7b1c594d5ab3074678c11ce1e9fe869 · melisgl/mgl-pax
<jackdaniel>
say "exactly once"
<jackdaniel>
(in the comment above load-time-value*
<jackdaniel>
)
<jackdaniel>
lgtm otherwise
<mgl>
Is that so in the interpeter case?
<jackdaniel>
the spec says that load-time-value is evaluated "only once"
<jackdaniel>
disregarding whether we interpret "only" as "at most" or "exactly", it is never "at least"
<mgl>
Does it? :-)
<jackdaniel>
yes
<mgl>
I missed that part of the conversation :-)
<mgl>
OK. I change the comment.
<jackdaniel>
well, gilberth argues (on behalf of Bruno) that "only once" means "no more than" -- it is contrary to my knowledge about the language, but such argument did happen
<mgl>
Yes, yes, I know.
<mgl>
Anyway, popping the rabbit hole stack, just below L-T-V*, there is an implementation of NOTE that uses it. As the docstring explains, it is weird to define stuff at macroexpansion time, but I see now way around it.
<jackdaniel>
of course (AND (at-least-once) (at-most-once)) is (excatly-ocne)
King_julian has joined #commonlisp
wbooze has quit [Ping timeout: 260 seconds]
decweb has joined #commonlisp
wbooze has joined #commonlisp
wbooze has quit [Quit: Leaving]
random-nick has joined #commonlisp
usagi_mimi has joined #commonlisp
varjag has joined #commonlisp
jjnkn has joined #commonlisp
surabax has joined #commonlisp
kiyafirs has quit [Remote host closed the connection]
zwr has quit [Read error: Connection reset by peer]
zwr has joined #commonlisp
JuanDaugherty has joined #commonlisp
grawlinson has quit [Ping timeout: 268 seconds]
wbooze has joined #commonlisp
wbooze has quit [Max SendQ exceeded]
wbooze has joined #commonlisp
wbooze has quit [Max SendQ exceeded]
wbooze has joined #commonlisp
JuanDaugherty is now known as ColinRobinson
ingeniot has quit [Ping timeout: 265 seconds]
bpanthi977 has joined #commonlisp
bpanthi977 has quit [Remote host closed the connection]
bpanthi977 has joined #commonlisp
cage has joined #commonlisp
grawlinson has joined #commonlisp
tr4gic_3rr0r has joined #commonlisp
dlowe has joined #commonlisp
dlowe has quit [Changing host]
dlowe has joined #commonlisp
King_julian has quit [Ping timeout: 244 seconds]
dlowe has quit [Remote host closed the connection]
dlowe has joined #commonlisp
stanrifkin has joined #commonlisp
zwr has quit [Read error: Connection reset by peer]
ingeniot has joined #commonlisp
zwr has joined #commonlisp
cercopith_ has joined #commonlisp
cercopith__ has joined #commonlisp
cercopith__ has quit [Client Quit]
cercopith_ has quit [Remote host closed the connection]
cercopith_ has joined #commonlisp
cercopith_ has quit [Client Quit]
Guest47 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]