freenode/lisp - IRC Chatlog
Search
20:29:09
burtons
Seems to be a low level problem with promises, with everything installed out of the lastest quicklisp.
21:17:58
k-stz
http://stackoverflow.com/questions/42426046/stopped-process-but-heap-is-still-changing if someone whats to guess with me. But it's only Lisp related to the extend that I'm building a Lisp program around it
21:25:46
TruePika
k-stz: ptrace(2) acts on threads, not entire processes; the second argument is the thread ID
21:28:08
k-stz
TruePika: ah thank you, that was me using pseudo code, I got the order right in the binding
21:36:42
k-stz
multiple threads sharing the same heap.. stopping one thread would still allow other threads to change it
21:39:50
k-stz
I'm checking if the heaps overlap and then I'm gonna stop them all.. this makes sense
21:46:23
k-stz
TruePika: well first of all thanks! SIGTSTP works, but now i have some more reading to do :)
22:16:45
lagagain
Why I have different result between with sbcl and with ecl? https://www.irccloud.com/pastebin/W4BJfqRc/Common%20Lisp%20-%20Hello%20World
22:18:09
lagagain
I think "Please Input your name" is show before input name, but sbcl, abcl is after input; clisp, ecl just I think.
22:19:56
scymtym
lagagain: the implementation is free to not write anything to your terminal before the READ-LINE call. add (finish-output) to force the output
22:25:08
TruePika
but that (DECLARE (IGNORABLE C D D E F)) should theoretically suppress the STYLE-WARNING issued
22:26:19
TruePika
yup, not unique to NST: (let* ((a 1) (b 2) (b 3)) (declare (ignorable a b b)) a) results in a STYLE-WARNING about defined and unused B
22:29:38
TruePika
I can't be sure if this is an SBCL bug, I don't see anything covering this in the hyperspec
22:34:45
TMA
TruePika: if LET* is expanded in the straightforward manner to a series of nested LETs, the declare remains in the innermost LET form
22:36:57
TMA
TruePika: therefore the ignorable is the second one, not the first one, which gets shadowed before being declared ignorable
22:39:32
TMA
TruePika: not without splitting the let* into (let* ((a 1) (b 2)) (declare (ignorable b)) (let* ((b 3)) (declare (ignorable a b b)) a))
1:53:49
krwq
hey, is there any way to make cffi-grovel fix include files? im seeing it is passing wrong paths to the compiler (they are missing c: on windows)
7:03:36
athan
I think i understand the notion of prefix operation (I can't remember the correct term) - but like `+ 1 2 == 3` etc
7:04:04
athan
I'm familiar with TemplateHaskell, but I don't think that is the same concept as lisp quoting... right?
7:04:34
halogenandtoast
athan: the best way to think about it, is that at run time you basically have full control over your AST
7:05:20
Bike
it's really pretty simple. (+ 1 2) evaluates to 3. '(+ 1 2) evaluates to a (linked) list of three elements.
7:05:25
beach
athan: Code as data will make sense once you start appreciating macros as a way of extending the syntax of the language, or a way of programming the compiler to understand new syntactic constructs.
7:07:36
athan
Bike: Yeah, that's how haskell treats lambdas - they're immutable, and the only way to reason about them is through application
7:08:04
beach
athan: A Common Lisp macro is a Common Lisp function that takes Common Lisp code (in the form of an internal representation as a data structure) and returns Common Lisp code (again, in the form of an internal representation as a data structure).
7:08:05
Bike
no, that's true in lisp as well. once you have a function you can't do much with it but check that it's a function and call it.
7:08:58
athan
beach: so in that case, it could be an array of terms (free / bound variables) or something?
7:09:58
athan
beach: I think that corrosponds to a morphism in haskell, of the type `AST -> AST`, to the degree that quoting turns code into data, then unqoting AST into actual code
7:10:47
beach
athan: Common Lisp code is represented as a syntax tree in the form of a combination of nested lists, symbols, numbers, and other atoms.
7:11:07
Bike
i think you might be overcomplicating this. lisp is seriously really simple about it. say you have like...
7:12:09
Bike
the first element is the symbol LAMBDA, the second element is a list of one element, the symbol X, and the third element is the symbol X.
7:12:32
Bike
in other words there is an extremely close correspondance between the program text and the data structure.
7:14:30
beach
athan: You may want to take what halogenandtoast says with a grain of salt, until he or she uses the right terminology.
7:14:45
Bike
lambda is an operator. it's not a function, because functions have their arguments evaluated normally.
7:15:12
Bike
i.e. (lambda (x) x) would call the function lambda with two arguments, the first of which is the result of calling the function named x, and the second of which is the value of the variable x. which would be silly
7:16:12
Bike
but i mean, it's like that in haskell too. if you write \x -> x you don't expect the value of x in the surrounding context to matter.
7:19:01
beach
halogenandtoast: (quote (lambda (x) x)), when taken to be a FORM, can be EVALUATED to produce (lambda (x) x).
7:19:39
beach
halogenandtoast: That doesn't mean that (quote (lambda (x) x)) "is the same as" (lambda (x) x).
7:22:38
beach
halogenandtoast: Again, be more careful with terminology. '(lambda (x) x) is a sequence of characters that, when processed by READ usually turns it into the expression (quote (lambda (x) x)).
7:25:02
Bike
there's a little difference in that in haskell, something like 4:5 is banned, but (4 . 5) is ok in lisp. it's called a "dotted list" cos there's a dot. but most lists end normally with ().
7:26:22
halogenandtoast
beach: I'm sorry if I was offensive. It just reminded me of the good ol' "It depends on what your definition of is is?" from Bill Cliton.
7:31:03
halogenandtoast
beach: since you didn't respond to my apology, I'll go a step further and thank you for you assistance. I'm not around enough lispers so my knowledge and application are maybe more topological (and wrong) then it should be if I'm to attempt helping someone.