<asarch>
As you already know, virtual functions actually helps C++ to do the polymorphism stuff
<asarch>
I just was wondering if this also was possible with CLOS
<beach>
That's a very different question.
<beach>
asarch: So the simple answer to your question is "no". But that doesn't mean that you can't do the things you can do in C++. It might mean that you don't need a special mechanism in CLOS whereas you do in C++.
<beach>
asarch: Which is why I wanted to know what particular characteristic of virtual functions you were looking for.
<beach>
asarch: I am guessing that no such special mechanism is required in CLOS.
rumbler31 has joined #lisp
shifty has joined #lisp
<beach>
For the record, I really dislike questions asked that way, i.e. "Does Common Lisp have the equivalent of the <mumble> feature in the <foo> language"? It presumes that 1) everyone knows the <foo> language. 2) that if <mumble> does not exist in Common Lisp, then Common Lisp is somehow inferior.
<beach>
I much prefer "What mechanism in Common Lisp would you use to solve the following problem...".
<asarch>
Thank you
<asarch>
Thank you very much guys
<beach>
asarch: Your parameter name and documentation for the generic function SHOW is wrong.
<asarch>
I guess that is the easiest way to ask things: "Can you do overload functions in Lisp?"
<beach>
The second one, I mean.
<beach>
You should not have two defgeneric with the same name.
rumbler31 has quit [Ping timeout: 264 seconds]
<beach>
asarch: It is not called overloading. It is called generic dispatch.
fikka has joined #lisp
<beach>
"overloading" is typically a compile-time mechanism, whereas "generic dispatch" is a run time mechanism, so much more powerful.
<loke>
asarch: I'm not sure you are using the C++ terminology correctly.
<asarch>
?
<beach>
Yeah, that's not overloading.
<loke>
asarch: “overload” menas that you can have several functions with the same name. It does not imply that the choice of which implementation to call is actually chosen at runtime.
<loke>
asarch: In C++, if you have two functions: void foo(int) and void foo(char), that's overloading.
<loke>
asarch: But for the compiler to be able to choose which function to call, you have to know the type at runtime.
<beach>
asarch: Consider a method FOO in some language like Java or C++. It has two signatures, each with one argument. One signature has a DRINK argument and another has a COFFEE argument (COFFEE is a subclass of DRINK). Now do a DRINK d = new(COFFEE) and then x.FOO(d).
<loke>
I mean at compile time.
<beach>
asarch: What method is called?
<asarch>
I thought: (defgeneric show (caffee) ()) and (defgeneric show (chocolate) ()) was actually the same :-(
<beach>
asarch: You should have a single defgeneric with a particular name.
Oladon has quit [Quit: Leaving.]
smurfrobot has quit [Remote host closed the connection]
smurfrobot has joined #lisp
<asarch>
Ok
<loke>
asarch: Here's another terminology tip for you: In C++ a “method” is a function that is attached to a class. In CLOS, a “method” is some actual code that _may_ be run when a generic function is called. The method is attached to the generif cfunction,. not to a class.
fikka has quit [Ping timeout: 276 seconds]
smurfrobot has quit [Remote host closed the connection]
<loke>
asarch: Once you learn that single fact, the rest becomes much more clear.
<beach>
asarch: So which method would be called in my example? The one with a DRINK argument, or the one with a COFFEE argument?
<asarch>
Warte bitte
<beach>
asarch: Oh, you are cheating by writing the code?
<asarch>
No, I'm not
<beach>
OK.
<loke>
Beach's statement sounded weird, until I replaced the word Drink with Beverage in my mind. :-) (drink being both a noun and a verb made me confused. I'm stupid :-) )
<beach>
Oh, sorry.
<beach>
Yes, BEVERAGE would have been better.
<loke>
Tacka vet jag Svenska :-)
<asarch>
I was actually reading the pages of the CLOS book from the "Object-Oriented Programming in Common Lisp" book from Sonja E. Keene
smurfrobot has joined #lisp
<beach>
loke: The Swedish language is a mess (like most others), but in this case it would have allowed us to distinguish between the verb and the noun, yes.
Cymew has joined #lisp
<beach>
asarch: You never answered my question.
<asarch>
Easy! It would call FOO(COFFEE), right?
<asarch>
I had another question for you but I cannot find it...
<asarch>
...from that book
<pillton>
Oh, we might get to debate dot notation.
Cymew has quit [Ping timeout: 256 seconds]
<beach>
asarch: No, that's wrong.
<beach>
asarch: Most object-oriented language do a run-time dispatch only on X and not on the argument of the method. Which method will be called in such a situation is resolved at compile time, so the answer is "wrong" in this case. CLOS has multiple dispatch, so it does not have that problem.
shrdlu68 has joined #lisp
vlatkoB has joined #lisp
fikka has joined #lisp
<beach>
It is interesting to me that there are lots and lots of programmers out there, using one of these languages professionally, to produce code that runs in applications that I might have to use, and who do not know this fact.
smurfrobot has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 260 seconds]
smurfrobot has joined #lisp
<asarch>
I didn't know
<asarch>
All my OOP knowledge is class from C++ and Moose from Perl (the reason I am here)
<beach>
asarch: Are you still a student?
<asarch>
I even bought the "The Art of the Meta Object Protocol" book when I was learning to use the web development framework from Perl: Catalyst
nickenchuggets has quit [Read error: Connection reset by peer]
<asarch>
When I was working as an English teacher, all I wanted was a web application to keep all the related stuff for my students
<asarch>
That's why I learned Catalyst
<beach>
What is taught by a typical 5-year masters program (according to the Bologna system) is simply not enough to program professionally. But industry does not know that. So either we need to train industry to continue educating the programmers after they start working, or we need to define some kind of doctoral-level teaching program that should then be a requirement for working in industry.
<beach>
Stuff like this (overloading, single/multiple dispatch, etc) should be part of such a training program.
<aeth>
people have strong opinions about paradigms, and those strong opinions change with fashion, and the fashions change too quickly for programs to keep up
vhost- has joined #lisp
vhost- has joined #lisp
vhost- has quit [Changing host]
<mange>
beach: Maybe I misunderstand you. Are you saying that people should get a PhD before programming in industry?
<aeth>
mange: I think what beach is saying is that masters degree programs teach the wrong thing
smurfrobot has quit [Remote host closed the connection]
light2yellow has joined #lisp
<beach>
mange: It would not be a PhD, but some other doctoral-level program. A PhD is a research-oriented program, so that might not be well adapted to this situation.
<pillton>
A post-graduate course.
<beach>
Yeah, but my estimate is that it would take at least 2 years after a masters degree, so a doctoral-level program would be possible.
<beach>
And, of course, as a Lisper, I consider it totally unacceptable for anyone who will program professionally not to have knowledge about Common Lisp, CLOS, MOP, etc. If for no other reason, to avoid re-inventing the wheel and being able to compare to what they are forced to use.
<MichaelRaskin>
I think the industry has recently discovered that what they want is trainable in one year (_instead_ of 5-year program). They don't care much for anything to work when they cannot define «working» code even postfactum
<beach>
MichaelRaskin: Yes, I am talking about what industry NEEDS, not what it WANTS.
<beach>
The big mistake in academia is to think that industry NEEDS what it WANTS, which results in our teaching programs being a disaster.
<MichaelRaskin>
I think no amount of training programmers will help industry that doesn't care about correctness in specs _and_ defaults to not letting programmers talk to users directly and regularly
<beach>
You might be right.
<mange>
Yeah, I think the bigger problems are in the the industry's priorities, rather than training.
<asarch>
In your example beach, what is x? An instance of FOO oder COFFEEE?
<beach>
asarch: Possibly neither. x.foo(d)
<beach>
asarch: Not important here.
<beach>
asarch: x is an instance of the class that has two foo methods.
<beach>
asarch: x WOULD be used for dispatch (that's what single dispatch means). But the point of the example is that the run-time value of d is NOT used for dispatch.
fikka has joined #lisp
<aeth>
I don't think formal education is what you would want for programming training. perhaps my experience is skewed, but that tends to be research-oriented.
MichaelRaskin has quit [Quit: MichaelRaskin]
mathrick has quit [Ping timeout: 276 seconds]
<aeth>
(at least at the higher levels)
<shrdlu68>
Programming is, at best, a craft.
pjb has quit [Remote host closed the connection]
<aeth>
programming is like writing
<shrdlu68>
beach: The behavioral sciences call that the "scientist-practitioner" model.
pjb has joined #lisp
<asarch>
My formal education for C++ was: "Learning C++ in 21 days!" :'-(
<jdz>
Moloch does not care about people's feelings.
lavaflow_ has joined #lisp
orivej has joined #lisp
fikka has quit [Ping timeout: 265 seconds]
lavaflow has quit [Ping timeout: 248 seconds]
mathZ has left #lisp ["ERC (IRC client for Emacs 25.3.1)"]
smurfrobot has joined #lisp
mathrick has joined #lisp
milanj has joined #lisp
<xificurC>
I have a masters from something called maths & management, does that disqualify me from being a good programmer? :(
<beach>
What current post-graduate programs teach is beside the point. All I am saying is that people who program professionally often need way more knowledge than they get from a typical masters program. And since people working in industry are largely ignorant about such knowledge (which is why the don't WANT what they NEED), academia would have to be the place to define such a doctoral-level teaching program. Not that it would be easy,
<beach>
given that most university professors are ignorant too when it comes to that kind of knowledge.
<beach>
xificurC: I am not expressing myself very clearly, I can tell.
<beach>
xificurC: There are excellent programmers out there with absolutely no formal training.
<beach>
xificurC: So if you are one of them, you are definitely not disqualified.
<asarch>
Wow! What a very illustrative chat! Thank you guys!
<asarch>
Thank you very much :-)
<asarch>
Everything is in my notes now
<beach>
But, and this is the point, most programmers receive their only training in some university program (at most 5 years, more often shorter). For them to be excellent, they need more training.
AetherWind_GJ is now known as aetherwind
aetherwind is now known as AetherWind
<beach>
They are not going to do enough self study to become good, and the company they are working for is not going to train them either.
vutral has quit [Ping timeout: 265 seconds]
<asarch>
So viele Fragen und so kurz dieses Leben :'-(
<beach>
Indeed.
<beach>
asarch: So did I manage to communicate the issue with x.foo(d)?
<shrdlu68>
Perhaps an economic model can explain this? The programmers in company X only need to be as good as they ought to be to have some advatage over company Y.
<xificurC>
beach: my note was only written to let you further drive your point. Not that it wasn't true
<xificurC>
I'm no *excellent* though
<shrdlu68>
i.e "good" here is relative, and the "evolutionary pressures" are not very harsh.
<White_Flame>
beach: wait, you would consider understanding C++-family OO dispatch to be doctoral level?
<xificurC>
imho studying n years has no point when one doesn't enjoy the field and does self training
<beach>
White_Flame: It currently is, as in, it is not communicated at the masters level.
<White_Flame>
wow
<asarch>
Yes, you did beach. I thought 'x' was everything in this case
<White_Flame>
and yeah, that's why programming remains a craft
<White_Flame>
because you hit this stuff in practice
<beach>
White_Flame: I asked the same question to several masters-level students about to graduate, and they had no clue.
<loke>
beach: When I interview candidates for jobs that require programming experience, I make a point of trying to figure out how they learned it, and what drives them.
<beach>
White_Flame: There is just not enough about programming-language implementation taught in these programs.
<loke>
If the only practical programming projects they worked on was school projects, it's usually a red flag.
<beach>
White_Flame: "What's the point, nobody is ever going to write a compiler".
<beach>
loke: Yeah.
<White_Flame>
loke: of course, they do have to learn somewhere
<White_Flame>
it's not the end of the world to expect them to learn on the job, if they seem like good learners otherwise
<loke>
White_Flame: Right, but if you're interestd in the topic, there is no reason why you wouldn't be working on personal projects.
SenasOzys has quit [Remote host closed the connection]
smurfrobot has quit [Remote host closed the connection]
SenasOzys has joined #lisp
smurfrobot has joined #lisp
<asarch>
I remember my next question: reflection and type introspection. Does Common Lisp support those features?
<loke>
asarch: Common Lisp is a dynamically typed language.
<asarch>
I found the link while I reading the Smalltalk entry at Wikipedia
C-16 has joined #lisp
<White_Flame>
the only weakness with introspection is structures; everything else is fine with reflection & introspection
shifty has quit [Ping timeout: 264 seconds]
<loke>
asarch: You can't have a dynamically typed language without it
<White_Flame>
but there are usually non-standard ways included to fully introspect structs if you want to; normal class-based objects are fully introspectable
<asarch>
So, in short, Common Lisp actually does support them, right?
<White_Flame>
however, you generally don't need to introspect much because macros can create whatever metadata you need directly
<White_Flame>
so in practice it's used far less than other languages
<loke>
asarch: Yes. To a more comprehensive degree than any other language I know of
<pillton>
asarch: There is also a difference between a type and a class. Types denote sets in common lisp and classes denote representation.
SenasOzys has quit [Ping timeout: 260 seconds]
Cymew has joined #lisp
flamebeard has joined #lisp
<asarch>
Thank you guys
<asarch>
Thank you very much :-)
smurfrobot has quit [Remote host closed the connection]
pierpal has joined #lisp
Cymew has quit [Ping timeout: 276 seconds]
Cymew has joined #lisp
angavrilov has joined #lisp
Cymew has quit [Ping timeout: 268 seconds]
Cymew has joined #lisp
oni-on-ion has quit [Remote host closed the connection]
doesthiswork has quit [Quit: Leaving.]
oni-on-ion has joined #lisp
flamebeard has quit [Remote host closed the connection]
AetherWind has left #lisp ["Leaving"]
mange has quit [Remote host closed the connection]
flamebeard has joined #lisp
dddddd has joined #lisp
asarch has quit [Quit: Leaving]
jinkies has quit [Remote host closed the connection]
Tristam has quit [Read error: Connection reset by peer]
Tristam has joined #lisp
orivej has joined #lisp
light2yellow has quit [Quit: light2yellow]
Smokitch has joined #lisp
<xificurC>
uiop:run-program says :interactive makes the subprocess inherit the current output and that it can be different from *standard-output*. Why and how?
<jackdaniel>
as of why and how (regarding uiop interfaces), sometimes answer is: because it could; in a very hacky way involving internal implementation interfaces. just a general observation of a regular user who tries to make sense of some of these
Bronsa has joined #lisp
<xificurC>
jackdaniel: it says e.g. in SLIME it would behave differently if it just used *standard-output*. Are you saying SLIME is using one of those hacky ways?
<xificurC>
jackdaniel: not "are you saying", rather "is"
Naergon has joined #lisp
<jackdaniel>
I don't know what is this "current output" in your description, but if it is the lisp implementation process stdio, then SLIME has nothing to do with it (slime binds *standard-output* to a gray stream; uiop may want something with a descriptor, that is stdout)
smurfrobot has quit [Remote host closed the connection]
smurfrobot has joined #lisp
<jackdaniel>
for instance ECL allows accessing these things with exported symbols in EXT package (like ext:+process-standard-output+)
<jackdaniel>
yes, I saw these monster docstring once or twice. that probably means, that it does what I have mentioned - tries to access process stdio
<xificurC>
jackdaniel: you don't seem to be a big fan of uiop
<xificurC>
jackdaniel: I started using it thinking it's one of those libraries that helps to write portable code
<jackdaniel>
I'm not an enthusiast of it, you are right
<jdz>
Monster docstrings you say? Have you seen the docstring of drakma:http-request?
smurfrobot has quit [Ping timeout: 255 seconds]
<jackdaniel>
I won't start rant on it, because there is a lot of work and testing put to it, I just happen disagree with a lot of things in this library (and some of decisions which stand behind these things)
<jackdaniel>
happen to disagree*
<shrdlu68>
I wish docstrings aligned horizontally, starting at the same point on each line.
fikka has joined #lisp
brendarn has quit [Read error: No route to host]
<jackdaniel>
imho docstrings should provide short contextual reminder (for a person who has read the documentation having lengthier discussion of the interfaces)
<beach>
shrdlu68: Easy to obtain. Use #.(format nil "...")
<beach>
shrdlu68: Then you can use the ~@ format directive and indent following lines.
_cosmonaut_ has joined #lisp
<beach>
shrdlu68: But maybe you meant that you wish that the author had done just that.
troydm has quit [Ping timeout: 276 seconds]
fikka has quit [Ping timeout: 240 seconds]
<shrdlu68>
Wouldn't it be better to fix this in the text editors?
<shrdlu68>
Could you link to the docs for the ~@ directive? I only know of @ as a modifier to other directives...
Folkol has quit [Read error: Connection reset by peer]
<beach>
@ is a modifier.
<beach>
"Tilde immediately followed by a newline ignores the newline and any following non-newline whitespace[1] characters. With a :, the newline is ignored, but any following whitespace[1] is left in place. With an @, the newline is left in place, but any following whitespace[1] is ignored."
Folkol has joined #lisp
<shrdlu68>
Heh, that makes much more sense, and is visually much more appealing.
<beach>
Yeah, using it means you don't have to ruin the overall layout of your code. Plus, Emacs is not always happy when there is text in column 0 that is not the beginning of a top-level form.
msb has quit [Ping timeout: 276 seconds]
msb has joined #lisp
smurfrobot has joined #lisp
EvW1 has joined #lisp
orivej has quit [Ping timeout: 256 seconds]
schweers has joined #lisp
smurfrobot has quit [Remote host closed the connection]
shifty has joined #lisp
kuribas has joined #lisp
<shka>
hello
<shka>
i need to stream large file via http into lisp client
<shka>
stream, because i can't afford reading/writing it at once
<loke>
shka: you can ask drakma to return a stream that you can read from
<loke>
use :WANT-STREAM T
<shka>
loke: thank you, although i already found it in manual
<shka>
shrdlu68: true that
smurfrobot has quit [Remote host closed the connection]
<loke>
shka: Remember to check the needs-close return value and close the stream if it's true
<shka>
good point
<shka>
loke: why can't i simply close stream blindly though?
<loke>
shka: I don't know what happens if you close an already closed chunked-stream.
<shrdlu68>
shka: You'll leak file descriptors?
C-16 has quit [Ping timeout: 276 seconds]
<shrdlu68>
Ah sorry, that makes no sense.
<shka>
shrdlu68: not if closed
<shka>
loke: ok, good point
<jackdaniel>
shka: closing already closed descriptor may lead to the segfault
<jackdaniel>
shrdlu68: *
<jackdaniel>
I remember debugging this kind of issue in usocket (someone put there indifferent closing of the descriptor what caused problems, you may check closed issues for details)
smurfrobot has joined #lisp
<jackdaniel>
(also, if the descriptor is valid again - because someone in the meantime opened something else - you kill randomly in your process)
pbgc has joined #lisp
C-16 has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
smurfrobot has quit [Remote host closed the connection]
chens has quit [Remote host closed the connection]
<theemacsshibe[m]>
Sometimes drakma doesn't pick up on text files (such as those put out by matrix servers). Is there a way to force it to put out a utf8 string? :external-format-in didn't work.
<shka>
shrdlu68: i can't seem to find needs-close function
<shka>
did you ment open-stream-p?
<jackdaniel>
sixth value of http-request
<loke>
theemacsshibe[m]: yes.
<loke>
force binary and then decode yourself
<jackdaniel>
read into want-stream parameter description
<theemacsshibe[m]>
How should I go about decoding it?
<theemacsshibe[m]>
Wait actually I think the docs said DRAKMA:DECODE-something does it, I'll have to check.
<theemacsshibe[m]>
DECODE-STREAM might take some work to process a vector, but flexi-streams has vector to stream conversion.
<shka>
jackdaniel: oh, ok
fikka has joined #lisp
<loke>
theemacsshibe[m]: You can decode binary using BABEL
<shka>
jackdaniel: sixth value returned from http-request?
<jackdaniel>
welcome you are
<jackdaniel>
I'd stick to the second remark, to read into want-stream parameter description
<theemacsshibe[m]>
That sounds much more sane, loke
<jackdaniel>
and experiment myself (eventually look in the source code)
fikka has quit [Ping timeout: 256 seconds]
scymtym has quit [Remote host closed the connection]
<shangul>
It says I have undefined variables(nm and mn) in the function main: https://apaste.info/aHXq
<shangul>
and also in ask-max-3
<jackdaniel>
shangul: defvar creates a special binding globally, if you put it in runtime mn and nm are not available when function is compiled
<jackdaniel>
you shouldn't use defvar this way
<jackdaniel>
if you want to introduce variables in the "main" function scope, you should use let operator
<minion>
shangul: please see pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
<shangul>
jackdaniel, that's what I'm reading
<beach>
shangul: Or, in case you really want to share the variable globally, use DEFVAR at the top-level and SETF to assign to it.
<jackdaniel>
oh, cool
<beach>
shangul: But in this case, you don't so use LET as jackdaniel suggests.
<shangul>
beach, why setf?defvar already does the initial assignment?
<shangul>
it doesn't?
<beach>
shangul: Yes, but the way you programmed it, it re-creates the variable each time you execute the function. That's not good style. The good style is to create the variable at compile time as a top-level form, and to assign to it inside the function.
<jackdaniel>
shangul: one of defvar characteristics is that it doesn't alter already existing bindings. so if you evaluate (defvar *nm* 3) and after that (defvar *nm* 4) *nm*'s value will be still 3
<jackdaniel>
also it is worth remembering, that global bindings should be put in earmuffs, like that: *variale*
smurfrobot has joined #lisp
<beach>
shangul: Worse, in this case, the variable is actually not created until the function is executed the first time, so the use of an un-created variable is what gives you the warning.
<jackdaniel>
it is a convention followed by all CL programmers
<shangul>
okay, thanks jackdaniel and beach
<shangul>
good pjb is not around to see this mess
<shangul>
which I've made
<shangul>
jackdaniel, but shouldn't I define the variable when using let?
<beach>
shangul: Line 19 is not indented properly, and the format is not inside the LET* as far as I can see.
<xificurC>
shangul: this was formatted with emacs' common-lisp-mode
<shangul>
xificurC, which?
Mandus has joined #lisp
lavaflow has quit [Read error: Connection reset by peer]
nsrahmad has joined #lisp
<xificurC>
shangul: another thing I would hope is idiomatic is to either have the if on one line or have the then and else part on separate lines, as I have done
dmiles has joined #lisp
<beach>
shangul: I agree with xificurC.
<xificurC>
you had (if test #\newline then else), that's hard to read. Either (it test then else) or (if test #\newline then #\newline else)
<xificurC>
shangul: machines don't care, you can write everything in 1 line and will read the source code fine. You and people reading your code however will need to reason about your code. Indenting correctly makes reasoning simpler.
igemnace has joined #lisp
<shangul>
xificurC, that's what I have in ask-max-3: if test <newline> then test
<shangul>
How should I enable emacs' common lisp mode?
<shangul>
forget it I'm searching
<xificurC>
shangul: you had "(ask-max-3 prompt) input-string)))". That's tricky to me :) I can read (if ... (ask-max-3 prompt) input-string) because I see the if will be a one-liner. But when the then gets its own line I expect the else to get its own too. Remember that an if's else is optional
<shangul>
xificurC, check the new version
<xificurC>
shangul: your format in main got into the bindings part of let*. I don't think that even compiles, does it? :)
<shangul>
no
<shangul>
<beach> shangul: Line 19 is not indented properly, and the format is not inside the LET* as far as I can see.
<xificurC>
shangul: yes but let is (let ((var1 val1) (var2 val2) ...) code-here-that-sees-var1-var2-...)
<xificurC>
shangul: you wrote (let ((var1 val1) (var2 val2) code-here-that-sees-var1-var2) nothing-here)
Mandus has quit [Ping timeout: 245 seconds]
<shangul>
well it's hard to see where anything is
<xificurC>
shangul: that's only the initial feeling :) Once you and your brain get used to it it's easier to read than put-your-language-here
<xificurC>
shangul: what languages do you know?
pierpal has quit [Quit: Poof]
<shangul>
xificurC, human or programming?
pierpal has joined #lisp
<xificurC>
shangul: it's much easier to write lisp in emacs with paredit/smartparens/lispy, or some other editor with equivalent tooling
<xificurC>
shangul: programming
orivej has joined #lisp
<shangul>
xificurC, I'm using emacs and I used to work with C_children_languages + a little 8086 assembly
<xificurC>
shangul: C_children_languages is a very loose term, would you include java there? How about javascript? I'm not sure what makes a language C's child
beach` has joined #lisp
<shangul>
xificurC, mostly C#(it's Java's clone), Python, C and less than these: Lua, C++ and Perl
<shangul>
I thought I should come out of this family, so I'm learning Lisp
<xificurC>
shangul: anyway, foo(1, 2); becomes (foo 1 2) in CL. 1 + 2 becomes (+ 1 2). if (...) {...} {...} becomes (if test then else). It's less effort
foom2 has joined #lisp
<shangul>
right
igemnace has quit [Read error: Connection reset by peer]
<shangul>
except that it's if (...) {...} else {...}
siraben has joined #lisp
nsrahmad has quit [Quit: Leaving]
<xificurC>
shangul: you just need to get a well tweaked editor and parens won't be a problem. If you're using stock emacs have a look at paredit (or lispy if you feel more brave0
<xificurC>
shangul: right, typo
<shangul>
what are those? lispy and paredit. emacs' plugins?
beach has quit [Ping timeout: 260 seconds]
<xificurC>
shangul: yes. Paredit is for PAREntheses EDITing. Lispy is a bit more than just that
<jackdaniel>
I wouldn't concern myself with editor enchancements for now, just try indent lines by myself. but that's just my opinion
<jackdaniel>
otherwise a lot of power will go into learning the tools (not the language)
foom has quit [Ping timeout: 276 seconds]
<xificurC>
while I agree there's also a cost involved when one has to manually match the closing braces and see compilation errors when one misses one. Not sure which option takes more effort
<jackdaniel>
compilator errors require correction which improves language understanding, but as I said, it is just an opinion of mine
<xificurC>
jackdaniel: "global bindings should be put in earmuffs, like that: *variale* ... it is a convention followed by all CL programmers" <- I was stunned when reading Let Over Lambda :)
<jackdaniel>
xificurC: I haven't read it, does the author violate this convention?
smurfrobot has joined #lisp
siraben has quit [Quit: ERC (IRC client for Emacs 26.1)]
<shangul>
jackdaniel, about that convention, is that just a convention followed by programmers or those "earmuffs" make a variable global?
<jackdaniel>
shangul: it is just a convention, but very important one
<jackdaniel>
it helps you to understand context better
<jackdaniel>
*earmuffed-variables* stand out, and it is good, because global bindings are (usually, I'm ignoring sb-ext:defglobal for now) dynamic
<jackdaniel>
dynamic bindings are very useful, but may be quite fishy when it comes to understanding the code
<jackdaniel>
earmuffs are a warning: fish ahead
<shangul>
aha
<xificurC>
jackdaniel: "Since this convention is almost like having another namespace for dynamic variables, diminishing their duality with lexical variables, this book does not follow it exactly."
<shangul>
should I change anything else in the last version?
<jackdaniel>
shangul: looks good. I think xificurC had also remark about if (which was valid), except that nothing wrong with the code as far as I can see
<jackdaniel>
xificurC: interesting. I find having them in the same namespace being one of CL's flaws on the other hand
<xificurC>
I said 1 line or separate then and else on new lines. He went with 1 line
<shangul>
oh sorry
<shangul>
I should fix that
<xificurC>
you made the whole if stand on 1 line, which is fine by me
<Bike>
in other words the docstring is shared betwen distinct closures with the same underlying function
<Bike>
does that seem at all problematic to anybody?
<Ukari>
is there been exist a function lexical scope stuff which looks like let or defvar?
Lauven has quit [Quit: leaving]
<Bike>
flet?
<Ukari>
I found that use let makes code nesting, and (let ((x)) (setf x)) would change x again and again
<beach>
Bike: I think it is entirely reasonable to share the documentation.
<Bike>
Me too, but spooky action at a distance is spooky enough that I'm wondering if anyone disagrees
<beach>
Fair enough.
<Ukari>
not the flet, it seems that no exist
<beach>
Ukari: That code snippet does not make much sense.
<beach>
Ukari: In fact, what you say does not make any sense to me.
<beach>
Ukari: FLET does exist. You can be sure of that.
<beach>
Ukari: And it creates lexical functions.
Chream has joined #lisp
fikka has joined #lisp
<Ukari>
"not the flet, (the stuff i want ) it seems that no exist"
<beach>
Ukari: That might be possible. But I for one do not understand what it is that you want.
<Ukari>
flet exist, i know it defines named function
<beach>
Ukari: Yes, but "is there been exist a function lexical scope stuff which looks like let or defvar?" makes no sense to me.
quazimodo has quit [Ping timeout: 240 seconds]
<beach>
... even if I let the grammar problems pass.
<beach>
I don't know what a "function lexical scope stuff" is.
<xificurC>
try siri
<beach>
And LET and DEFVAR don't look anything alike, so I don't know what they have in common.
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
<Ukari>
pastebin.com/qrn0Edsx
<schweers>
Are named function (e.g. created with defun) scoped in the same way as special variables? I’ve always been a little confused about this issue. background: I want to rebind a function for a dynamic extent, and am not sure how to do this in a safe and portable way.
fikka has quit [Ping timeout: 256 seconds]
<Ukari>
defun seems to be package scoped
<beach>
Ukari: Perhaps LET* is what you want?
<Bike>
schweers: defun makes global functions thathaveglobalscope.
<Ukari>
beach, LET* would make code nested
<Bike>
schweers: flet and labels have lexical scope. there is no operator for dynamic function binding.
<beach>
Ukari: How would it make the code nested?
asarch has joined #lisp
<xificurC>
Ukari: are you looking for scheme-like define-in-define behavior?
<asarch>
What is the name of the factorial function from "the standard library"?
<asarch>
Bingo! cl-alexandria - Collection of portable Common Lisp utilities
<antoszka>
asarch: available in QuickLisp
<beach>
asarch: I am a little troubled by your recent questions. It seems like you are collecting random keywords from the specifications of other programming languages, and asking whether those features exist in Common Lisp? What is the point of this exercise?
<xificurC>
Ukari: there's no such thing. If you really, really want it you can write a macro. You should get used to the nesting though. And if you feel like code is nesting too much then you are already in trouble
<beach>
Ukari: Can you tell me what it is that you dislike about my solution to your problem?
<asarch>
Well, the next programming language I would like to learn is Smalltalk. And while I am reading its entry in Wikipedia, I found that in ST "42 factorial" is the way to send messages to the objects
<beach>
Ukari: Is it the fact that My lines would have 4 more positions of indentation?
<asarch>
"42" would be the message receiver while "factorial" is the "message selector"
<xificurC>
yes
fikka has joined #lisp
<asarch>
While reading this, I was wondering how much would !42 be
<Bike>
It's pretty big.
<Ukari>
pastebin.com/LTvswbPH, different between nested and not-nested
<asarch>
So I started sbcl and typed: (! 42) and bum! There is no one :-(
<Ukari>
you way is accepectable, beach
<Bike>
Programming at random won't get you far, it's true.
Smokitch has quit [Remote host closed the connection]
<asarch>
Common Lisp is a beautiful programming language, sadly I'm infected with C++ "techniques" which I need to forget in order to get the most of Common Lisp
<beach>
Ukari: If you really care about such things, I recommend you use a different programming language, because that is totally not how Common Lisp works. A form that introduces bindings also introduces scope.
<xificurC>
Ukari: scheme has this, CL doesn't. I don't think people miss this
<asarch>
While doing this, hundreds of questions plague my mind
housel has quit [Remote host closed the connection]
housel has joined #lisp
<shka>
asarch: it is one of reasons to learn CL
<beach>
asarch: I totally understand. But the way to go about your quest is to figure out what you want done and ask how it is done in Common Lisp. Not taking some random keyword (virtual functions, for example) and asking whether Common Lisp has the same feature, which may or may not make sense in Common Lisp.
<asarch>
I know, I know. I really sorry about that
fikka has quit [Ping timeout: 265 seconds]
lavaflow_ has joined #lisp
<xificurC>
beach: and that's totally not how the human mind works. One always tries to compare things to something else they know to be similar. The problem is CL only *seems* similar
<beach>
Possibly.
orivej has quit [Read error: Connection reset by peer]
orivej has joined #lisp
<edgar-rft>
In Common Lisp all functions have some virtue, therefore they're all virtual.
FreeBirdLjj has joined #lisp
<shrdlu68>
I read that expecting "virtuous"
varjag has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
<Ukari>
xificurC, forget unknown cl syntax and use the lambda way, for example use (funcall (lambda (x) (print x)) 1) instead of (let ((x 1)) (print x))
fikka has joined #lisp
<xificurC>
Ukari: that's even more nested, and more importantly, less readable
<asarch>
Conrad Barski in his book says that "The power at your fingertips when writing Lisp code is what makes it so different. Once you “get” Lisp, you’ll be forever changed as a programmer. Even if you end up never writing Lisp code again for the rest of your life, learning Lisp will fundamentally change you as a coder."
<edgar-rft>
shrdlu68, sorry for disappointing your expectations.
lumm has quit [Quit: lumm]
pfdietz_ has joined #lisp
rippa has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
pfdietz has quit [Ping timeout: 265 seconds]
<edgar-rft>
asarch: Many ideas and concepts in lisp are pretty much different than in other programming languages. So even if you later never write lisp code, learning lisp teaches you to see more different perspectives to solve problems, raising chances to get things done. I think that's what C. Barsky means.
<schweers>
Bike: thanks for the clarification
<schweers>
so if I want something like dynamic extent, I’ll have to do it myself? I’ve seen examples which use SETF on SYMBOL-FUNCTION in conjuction with UNWIND-PROTECT. Seemed reasonable, but wasn’t sure if was safe, especially in the presence of threads.
<Bike>
If you need to have a dynamically bound function you could do like (defun foo (&rest args) (apply *foo* args)), and then do whatever with *foo*
smurfrobot has quit [Remote host closed the connection]
smurfrobot has joined #lisp
<shrdlu68>
asarch: It would probably still be my favourite language even without macros.
<schweers>
I guess such a function should be safe to declare inline
<schweers>
but it bothers me a little to do it like that, as it means I can’t do it for existing functions without editing every caller
<shrdlu68>
Well, maybe not - but there'd still be so many cool things about it.
fikka has joined #lisp
<Bike>
schweers: why would you have to edit every caller?
eli_oat has quit [Quit: Leaving.]
<schweers>
Bike: forget it, you’re right, I don’t have to do that. My bad.
<shrdlu68>
Think he meant "recompiling"
FreeBirdLjj has quit [Remote host closed the connection]
cage_ has joined #lisp
<Bike>
dynamically binding functions is pretty unusual, by the way. think hard before you do it.
nika has joined #lisp
tax has joined #lisp
<jackdaniel>
interesting idea though
fikka has quit [Ping timeout: 260 seconds]
<schweers>
asarch: learning and “getting” lisp not only changes you as a programmer, it spoils your character.
robotoad has joined #lisp
_cosmonaut_ has joined #lisp
Arcaelyx has quit [Ping timeout: 265 seconds]
<Bike>
contextl does stuff like that and it's kind of neat, but i don't entirely get it either.
<Ukari>
oh what happend, I use the sbcl context exist since yesterday, (lambda* (x) (print x) (yield (+ x 1))) (funcall * 5) (funcall *), then it prints 2. after i restart sbcl, the same code prints 5
robotoad has quit [Client Quit]
robotoad has joined #lisp
fikka has joined #lisp
mindCrime has quit [Ping timeout: 256 seconds]
rumbler31 has joined #lisp
<schweers>
Bike: I know it is, and I guess it’s normally unusual for good reason. I’m thinking about a testing context.
buffergn0me has joined #lisp
<schweers>
I’m not going to run around doing this immediately, but my idea was to find out whether this is useful in order to mock/stub/fake/whatever a function during testing.
fikka has quit [Ping timeout: 240 seconds]
<schweers>
but the more I think of it, the less happy I am as I see more problems with the approach
rumbler31 has quit [Ping timeout: 276 seconds]
<flip214>
Fare: please send me the link to that -- it's one more template to copy off of ;)
<Ukari>
oh i know what happend now, i excuted '(defvar x 2)' before
<phoe>
Ukari: DEFVAR does not always assign the value you pass to it
<phoe>
(defvar *foo* 3) (defvar *foo* 5)
<phoe>
*foo* ;=> 3
<phoe>
if *foo* is already bound, then DEFVAR does not change that binding.
<phoe>
use SETF for altering already existing bindings, or, if you are not sure if the binding has been created before, DEFPARAMETER will *always* set the new value.
<Ukari>
(defvar x 2) (lambda (x) (lambda () (print x))) , and then (funcall * 5) (funcall *). why it print 2 ?
<phoe>
Ukari: the variable X is now globally special
<Ukari>
is x in (lambda (x)) lexcial?
<phoe>
no
<phoe>
DEFVAR proclaimed X globally special.
<Ukari>
it is not safe
fikka has quit [Ping timeout: 240 seconds]
<phoe>
This is why global dynamic variables are always expected to be named with *earmuffs*.
<phoe>
this is to avoid such confusion.
Chream has quit [Remote host closed the connection]
<Ukari>
if i want to write lambda, it is not safe to naming the lambda argument
<phoe>
no, it is not safe to pass any non-earmuffed symbol to DEFVAR or DEFPARAMETER.
<Ukari>
well
<phoe>
you should be able to name your lambda parameters in any way you'd like. (except for constants, that's an error.)
<phoe>
BUT
<phoe>
anything that is in *earmuffs* is presumed to be a global dynamic variable.
<Ukari>
but without earmuffed?
<Fare>
flip214, see https://bbt.legi.cash/ for my slides at LambdaConf 2018 (videos to come in the next few months).
<phoe>
anything that's not - it's presumed to be a lexical variable.
<phoe>
or, in some special cases, constants, such as PI.
<Ukari>
so PI is not recommand to be used for name a lambda parameter?
karlosz has joined #lisp
<Fare>
flip214, our code is using a lot of modules and functors, so in CL you might want to translate that to Interface passing style.
<phoe>
Ukari: well, you can try to use it.
<phoe>
Lisp will signal an error if you do. (:
flamebeard has quit []
<phoe>
constant names are not allowed as variable names in Lisp.
<flip214>
Fare: thanks a lot, will take a look!
<Ukari>
i get it, thanks you, phoe
Khisanth has quit [Ping timeout: 240 seconds]
<Ukari>
would it be a good idea to make lamdba and defvar check their parameter's name to enforce name style?
fikka has joined #lisp
<beach>
No.
fikka has quit [Ping timeout: 255 seconds]
lumm has joined #lisp
<buffergn0me>
That would be really annoying. Especially when porting code from other languages
kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
pierpal has quit [Quit: Poof]
FreeBirdLjj has joined #lisp
pierpal has joined #lisp
fikka has joined #lisp
<beach>
Ukari: Lambda is perfectly able to use special variables as parameters. What that means is that the special variable gets bound upon entry to the function and unbound upon exit. For example ((lambda (*print-base*) (print 234)) 2)
fikka has quit [Ping timeout: 265 seconds]
<beach>
buffergn0me: It would be especially annoying because a conventionally named special variable could then not be used in a lambda expression.
<Ukari>
is that a lambda bug? pastebin.com/4D8X4rBg
<asarch>
schweers, D'oh! :-(
Khisanth has joined #lisp
nsrahmad has joined #lisp
<Bike>
It's not a bug. x is a special variable, and once the outer function has returned its binding of x is extinguished, so the inner function uses the global value.
<phoe>
Ukari: your compiler already does it
smurfrobot has quit [Remote host closed the connection]
<phoe>
in SBCL at least, (let ((*foo* 42)) ...) will emit a warning if *foo* is not declared special
<beach>
phoe: I think Ukari is suggesting that LAMBDA check that there are no earmuffs in the parameters.
fikka has joined #lisp
<phoe>
beach: (lambda (*foo*) *foo*) emits the same warning.
<phoe>
; caught STYLE-WARNING: using the lexical binding of the symbol (COMMON-LISP-USER::*FOO*), not the dynamic binding, even though the name follows the usual naming convention (names like *FOO*) for special variables
<Ukari>
I know why
<beach>
phoe: Sure.
<beach>
I guess I must have misunderstood the suggestion.
<Ukari>
pastebin.com/RieZHa8C
fikka has quit [Ping timeout: 240 seconds]
<Ukari>
in (lambda (x) (lambda () (print x))) or (let ((x 5)) (lambda () (print x))), when you funcall the outside lambda or get the let result, it returns you a FUNCTION
Folkol_ has quit [Ping timeout: 248 seconds]
<phoe>
yes
<phoe>
except X is special, so its value is taken from the dynamic environment and not the lexical one.
<Ukari>
but in (defun test (x) (lambda () (print x)))) , (test 5) returns a CLOSURE
<Ukari>
In a CLOSURE, a free variable in bind to its lexcial context, so use (defvar) won't change it.
<phoe>
Ukari: no
<Ukari>
in bind -> is bind
<phoe>
it returns a function in my case, and it won't matter anyway if a FUNCTION or a CLOSURE is returned
<phoe>
the only thing that matters is if X is proclaimed special
<phoe>
if it is, then the value of X will be taken from the dynamic environment
<Ukari>
it matters, look at examples in pastebin.com/RieZHa8C
<phoe>
if it is not, then the value of X will be taken from the lexical environment
<Ukari>
makomo, when (funcall *builder* 10) runs, the (funcall *builder* 10)'s result might be a CLOSURE or a FUNCTION, that determined by the context. Since you use (defvar x), x was treated as a global dynamic scope variable so (funcall *builder* 10) returns FUNCTION
<beach>
But it might be allowed to "compile" the function each time.
<karlosz>
especially if its using a bona fide interpreter
<dlowe>
also, in defvar, it mentions that its effects happen at compile-time.
<phoe>
beach: would treating that function with COMPILE NIL fix that?
<karlosz>
i dont think lcisps behavior is non conforming
<karlosz>
try compiling it
<karlosz>
itll probably give different results
<karlosz>
since then the compiler has to decide whether to treat x as special or not upfront
dieggsy has joined #lisp
<dlowe>
regardless, it's poor practice to rely on such inconsistent effects.
<karlosz>
whereas the interpreter always uses the runtime environment
<makomo>
ignore the output for a second, i'm using SBCL
<makomo>
LOAD-ing this lisp file gives 10 10 200, but compiling it and then loading the FASL gives an error: "X is unbound"
<makomo>
for the (print x) in the first defparameter for *builder*
<jackdaniel>
dlowe: you mean in documentation? how is this relevant to green threads? you may implement serve-event without gt (but I wouldn't be suprised if cmucl has them anyway)
FreeBirdLjj has quit [Remote host closed the connection]
shka_ has joined #lisp
<jackdaniel>
makomo: when you load a file, it is processed sequentially, toplevel form after toplevel form
<jackdaniel>
when you compile it things are quite different
<jackdaniel>
if you want to change that behavior you need to use eval-when
<jackdaniel>
but don't think too much about how it (eval-when) works in detail unless you have some time and want a good puzzle
schweers has quit [Ping timeout: 260 seconds]
smurfrobot has quit [Remote host closed the connection]
karlosz has quit [Ping timeout: 260 seconds]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
devon has quit [Ping timeout: 276 seconds]
Bronsa has quit [Ping timeout: 240 seconds]
guaqua has quit [Ping timeout: 245 seconds]
guaqua has joined #lisp
devon has joined #lisp
guaqua has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 264 seconds]
scymtym has quit [Ping timeout: 240 seconds]
nsrahmad has quit [Quit: Leaving]
fraya has quit [Remote host closed the connection]
Kaisyu has quit [Quit: Connection closed for inactivity]
guaqua has joined #lisp
azimut has quit [Ping timeout: 256 seconds]
sendai_ has joined #lisp
dyelar has joined #lisp
<makomo>
jackdaniel: i think i understand how EVAL-WHEN works because i've studied it a couple of times
<makomo>
jackdaniel: what i don't understand is what exactly is different between these two examples
<makomo>
DEFPARAMETER and DEFVAR both proclaim the symbol special at compile-time right
<Bike>
yes.
skapata has joined #lisp
<makomo>
hmm, does this have to do with the fact that the different stages of processing can be interleaved?
<makomo>
while with LOAD they're all sequential?
Smokitch has joined #lisp
<Bike>
Sanity check here: You restarted the image between loading and compile-file, right?
fikka has joined #lisp
<Bike>
Because when I compile-file and load in a fresh image I don't getan error.
tylerdmace has joined #lisp
tylerdmace has quit [Client Quit]
<gendl>
Hi, is anyone experienced with cl-json? I'm trying to encode a nested plist: (json:encode-json-plist (list :xaxis (list :visible nil)))
<gendl>
-->{"xaxis":["visible",null]}
<gendl>
so it looks like it only converts the outer plist into a JSON plist-type thingie. The inner one just becomes a JSON sequence or whatever TF they call it
<gendl>
I have a feeling I have to call json:encode-json-plist recursively somehow on the inner plists, but I'm not sure how I would make the result come out properly nested..
<Bike>
encode-json-plist presumably just calls encode-json for the values
<Bike>
and encode-json is documented to make an array for a list, unless you do the explicit encoder
<gendl>
Bike: with-explicit-encoder is exported but undocumented.
fikka has quit [Ping timeout: 248 seconds]
<Bike>
i don't know about that, but encode-json explains the layout
guaqua has quit [Ping timeout: 240 seconds]
nika has quit [Quit: Leaving...]
mareskeg has joined #lisp
mflem has joined #lisp
karlosz has joined #lisp
Lauven has joined #lisp
<gendl>
Indeed - the docs for method encode-json talk about the guessing-encoder and explicit-encoder. And it looks like using :object as (car S) is the same as using :plist. Anyway thanks for the pointers, this will let me do what I need.
guaqua has joined #lisp
scymtym has joined #lisp
pjb has quit [Read error: Connection reset by peer]
MichaelRaskin has joined #lisp
brendyn has quit [Ping timeout: 265 seconds]
fikka has joined #lisp
pjb has joined #lisp
sauvin has quit [Read error: Connection reset by peer]
<Bike>
please use a paste site for anything that takes more than a line
kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
fikka has quit [Ping timeout: 240 seconds]
<devon>
lol, that didn't come out as I expected.
mareskeg has quit [Quit: mareskeg]
lumm has quit [Read error: Connection reset by peer]
lumm has joined #lisp
noobly has joined #lisp
mareskeg has joined #lisp
devon has quit [Ping timeout: 276 seconds]
<makomo>
phoe: to conclude the whole discussion from today, the "error" with http://rextester.com/CQFO22548 was to assume that *builder* will refer to a compiled-function, right?
<makomo>
adding a (compile nil (lambda ...)) does fix the "issue", i.e. the difference in results when the file is loaded vs. when it's compiled and then loaded (using clisp of course, sbcl gives the same results in both cases)
lumm has quit [Ping timeout: 240 seconds]
<knobo>
or even (setf (symbol-function 'foo) (flet ((something (..) ..)) #'something))
noobly has quit [Ping timeout: 260 seconds]
lumm has joined #lisp
lumm has quit [Read error: Connection reset by peer]
lumm has joined #lisp
<knobo>
I can't think of anything but when evaluation occurs
<knobo>
Other then that, it's identical.
jmercouris has joined #lisp
warweasle has quit [Quit: later]
kajo has joined #lisp
fikka has joined #lisp
lumm has quit [Ping timeout: 245 seconds]
<Bike>
knobo: defun could do a few other effects, but that's the core semantic.
<knobo>
But (setf (symbol-fucntion 'foo) (labels ((foo (..) (..))) #'foo)) is different.
<knobo>
no... it
<knobo>
it's not.
Tristam has joined #lisp
<knobo>
return-from would not work.
fikka has quit [Ping timeout: 240 seconds]
<Bike>
oh. yeah ok. throw in a block.
<Bike>
by other stuff i meant like, keeping an inline definition around, informing the compiler to avoid warnings, blabla
<cgay>
I'm finding that slime-edit-definition doesn't always work when I already have the target file open in my buffer. i.e., it works the first time, when it has to open the file, but then later if I M-. the same symbol it jumps to the wrong place in the buffer.
<cgay>
Am I holding it wrong?
<cgay>
I think, but am not sure, that it just opens the buffer and leaves POINT alone.
<knobo>
The flet would be able to do return from.
moei has quit [Quit: Leaving...]
<Bike>
knobo: yeah cos it has an implicit block.
kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
<knobo>
cgay: I think you have to recompile the whole file if you edit parts of it (adding or removing lines).
<knobo>
or, maybe it's not that...
low_brain_cache has joined #lisp
rumbler31 has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 248 seconds]
<makomo>
phoe: i still don't understand why the value returned by *lambda1* is changed after defvar-ing x though
<Bike>
i haven't been able to reproduce that in sbcl
<makomo>
phoe: it makes sense that, since *builder* is an interpreted function, it might inspect x every time to check whether it's special or not and either return a closure or a function
<Bike>
do you mean in clisp?
<makomo>
Bike: yup, clisp
<Bike>
oh, well, yes. the interpreter presumably looks up whether the symbol is special at runtime.
<makomo>
Bike: this is the original example, not the one i linked to you (when i forgot to recompile the file)
<makomo>
just to make sure we're looking at the same thing
<Bike>
same principle
<makomo>
Bike: right, but why is the result of invoking *lambda1* changed as well?
<makomo>
it makes sense that the result of *builder* might be different depending on the specialness of x
<dlowe>
makomo: Have you literally spent all day on this?
<makomo>
but why is *lambda1* itself changed?
<makomo>
dlowe: well not really, but i have spent some time on it, yes :-)
<makomo>
dlowe: when learning something, one of the worst things you can do is say "meh whatever" and drop it, imo
<Bike>
The interpreter looks up whether a symbol is special before anything else, apparently
lavaflow_ is now known as lavaflow
<dlowe>
makomo: sometimes the experts will say "you're wasting your time on this trivial detail," and sometimes they're right.
<makomo>
i don't think that it's trivial though
<makomo>
maybe to someone else it is
<dlowe>
makomo: the code is open source and no one here knows the answers to the exacting detail you require
<makomo>
i like to understand the details
<White_Flame>
the compiler has to output machine code for the lambda, based on what it knows
vlatkoB has quit [Remote host closed the connection]
light2yellow has joined #lisp
<White_Flame>
you're compiling 2 different circumstances
<dlowe>
so I think your best bet (without any irony) is to actually dive into the compiler code for each to see why there's a difference
<makomo>
Bike: i guess. so even the lambdas that are returned inspect x over and over again
orivej has quit [Ping timeout: 248 seconds]
orivej has joined #lisp
<Bike>
yeah, i mean, that's what an interpreted function is like.
nickenchuggets has quit [Read error: Connection reset by peer]
zooey has quit [Remote host closed the connection]
<Bike>
evaluating a (lambda ...) might literally consist of just copying the body into an interpreted function object, and not examining it in any way.
nickenchuggets has joined #lisp
nickenchuggets has joined #lisp
nickenchuggets has quit [Changing host]
<makomo>
i guess it makes sense, but i thought that since in the first case a closure is returned, that it would just be "hardcoded" within the function
zooey has joined #lisp
<makomo>
but i guess a better model would be that it would evaluate X in its captured lexical environment
<makomo>
which is the proper model anyway i guess
<makomo>
but then when doing the evaluation it finds that x is special and bla bla
<Bike>
it is sort of an ambiguous case though. i can imagine interpreters that would treat it like a lexical binding.
<makomo>
mhm. so in the end it's implementation defined? and with compiled functions it is guaranteed that X will be considered either a lexical or a dynamic binding, depending on the specialness of the symbol X, as per the clause you linked, right?
varjag has quit [Ping timeout: 260 seconds]
<Bike>
it is for compile-file. with compile i'm not sure, but probably the same
<White_Flame>
SBCL does at least give warnings when you redefine some assumption that it baked in previously
<makomo>
Bike: any reason for the uncertainty or?
<Bike>
i just don't remember all the details of teh semantic constraints
<makomo>
ah, ok
<Bike>
whether a compiler could hypothetically be really dumb
herr_jth has quit [Remote host closed the connection]
<White_Flame>
the compiler does not appear to be mandated to bake in compile-time knowledge of specialness
Fare has joined #lisp
<White_Flame>
ah, but in 3.2.2.3: "Special proclamations for dynamic variables must be made in the compilation environment. Any binding for which there is no special declaration or proclamation in the compilation environment is treated by the compiler as a lexical binding."
<makomo>
so with compiled functions it's perfectly specified what happens
<White_Flame>
ok, that was a ways back in the log
<makomo>
with interpreted functions, a variety of behaviors might be observed
fikka has quit [Ping timeout: 264 seconds]
<White_Flame>
Bike's last comment was about a compiler, so I thought that was the target
<makomo>
does (compile nil (lambda (x) (lambda () x))) ensure that the functions returned by the inner lambda will be compiled too?
Lauven has quit [Ping timeout: 256 seconds]
<Bike>
yes.
Fare has quit [Ping timeout: 265 seconds]
<makomo>
and (lambda (x) (compile nil (lambda () x))) is undefined behavior?
<makomo>
"The consequences are undefined if the lexical environment surrounding the function to be compiled contains any bindings other than those for macros, symbol macros, or declarations."
pierpal has quit [Read error: Connection reset by peer]
angavrilov has quit [Remote host closed the connection]
fikka has joined #lisp
varjag has joined #lisp
SaganMan has quit [Ping timeout: 264 seconds]
fikka has quit [Ping timeout: 256 seconds]
pierpal has joined #lisp
pjb has joined #lisp
pierpal has quit [Ping timeout: 240 seconds]
makomo has quit [Quit: WeeChat 2.0.1]
Tristam has quit [Ping timeout: 240 seconds]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
fikka has joined #lisp
Tristam has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
kajo has joined #lisp
mareskeg has quit [Quit: mareskeg]
mindCrime has quit [Ping timeout: 256 seconds]
SaganMan has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
pierpa has joined #lisp
kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
dxtr has joined #lisp
fikka has joined #lisp
Fare has joined #lisp
fikka has quit [Ping timeout: 260 seconds]
Tristam has quit [Ping timeout: 260 seconds]
Bike has quit [Ping timeout: 260 seconds]
fikka has joined #lisp
fraya has quit [Remote host closed the connection]
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fikka has quit [Ping timeout: 268 seconds]
Tristam has joined #lisp
fikka has joined #lisp
dented42 has joined #lisp
devon has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
asarch has quit [Quit: Leaving]
<knobo>
Would a function created by def be garbage collected (defmacro def () (let ((n (gensym))) `(defun ,n () (format nil "t"))))
<knobo>
Or would calling (def) eat memory
<knobo>
every time it's called
<phoe>
knobo: wait a second
<knobo>
Since ,n is not interned.
fikka has joined #lisp
<phoe>
I think the global environment will contain a reference to that function
<phoe>
so it will stay around, even if you have no real means of accessing that function after it's defined.
Tristam has quit [Ping timeout: 240 seconds]
random-nick has quit [Ping timeout: 245 seconds]
<knobo>
Can I look at the global environment?
<aeth>
If it's in the global environment it has to still be there.
<aeth>
The global environment never goes away.
<phoe>
knobo: only via implementation-defined APIs, if any.
<phoe>
The standard does not specify anything like that.
<phoe>
Theoretically, the environment object could contain a weak hash table or something.
<phoe>
Like, if a symbol is no longer accessible, then all functions and variables named after that symbol may be collected.
devon has quit [Ping timeout: 268 seconds]
<phoe>
But I have no idea if such a thing happens. You could try checking it out yourself by defining a finalizer on the created function object and see if it ever gets triggered.
fikka has quit [Ping timeout: 264 seconds]
dxtr has quit [Remote host closed the connection]
LiamH has quit [Quit: Leaving.]
<knobo>
Interesting to think about these things.
<knobo>
an dlearn
<knobo>
and learn
<knobo>
But not so useful right now.
<White_Flame>
I would put a small wager on it getting collected
sjl has quit [Quit: WeeChat 2.2-dev]
Tristam has joined #lisp
fikka has joined #lisp
wheelsucker has quit [Quit: Client Quit]
foom2 is now known as foom
fikka has quit [Ping timeout: 256 seconds]
<pierpa>
you could call def repeatedly and observe the amount of free memory
lumm has joined #lisp
<pierpa>
not a proof, but a good hint
Tristam has quit [Ping timeout: 256 seconds]
rumbler31 has joined #lisp
dxtr has joined #lisp
fikka has joined #lisp
<pierpa>
in the implementation I'm using, they get collected.
<pierpa>
or maybe they aren't. wait a minute...
rumbler31 has quit [Ping timeout: 268 seconds]
<knobo>
(sb-ext:finalize (symbol-function (def)) (lambda (&rest a) (format t "yes~a~%" a)))
<knobo>
and then run gc
<knobo>
prints yes
<pjb>
There's no reason to keep those gensym'ed functions.
* White_Flame
cashes in his small wager
<pierpa>
I meant, in the implementation I'm using, they don't get collected.
<knobo>
(gc :full t)
<knobo>
pierpa: which one?
fikka has quit [Ping timeout: 265 seconds]
<White_Flame>
also, check *inferior-lisp* in case the output is threaded outside of slime
<pierpa>
knobo: I can't talk about it, as it is off topic here.