libera/#commonlisp - IRC Chatlog
Search
16:14:40
beach
Guest63: The terminology varies, but they certainly are if they are defined in a non-null environment.
16:15:01
tfb
Guest63: they're closures if they are define in a non-empty environment. Which they almost never are
16:15:07
Guest63
shka: thanks, yes that's what I thought. I guess they "predated" the idea of closures, but they basically are - since they have lexical scope on the bindings
16:16:01
jackdaniel
a pattern sometimes found in the wild: (flet ((some-local-utility (…) …)) (defun a () … (some-local-utility …)) (defun b () … (some-local-utility) …)))
16:16:19
tfb
Guest63: If you define a closure as a function which uses a free lexical binding, then no, but really the distinction is artificial
16:16:33
beach
Guest63: The terminology varies. You can say that it's a closure with an empty static environment. But more often you would then say that it's not a closure.
16:19:04
Guest63
shka: yep, agree. I was just writing some notes and wanted to put "recursion" under closures but it also applies to functions, that got me thinking
16:19:59
shka
i guess, this is this time when theoretical categorization has limited practical application
16:20:50
tfb
I think really that the whole 'closure' thing is a hangover from the days when you had to explicitly say 'I want to make a closure' rather than what you can do now which is just assume scope & extent work right
16:22:11
Guest63
beach: agreed, now that I think of it, they are related but don't really have anything to do with each other
16:22:49
Guest63
tfb: there is definitely a lot of terminology that is a hangover from older days, it does add a bit of complexity to learning the language
16:23:14
Guest63
but I guess once you do, you get better at computer science - since the terms are quite exact
16:26:34
iisi
ACTION defenestrates the word "orthogonal", for being used variously to mean: related, not related, intersecting, not intersecting, overlapping, not overlapping, intersecting at a 90 degree angle
16:26:42
shka
jackdaniel: when invoking recursive function, function lookup may be performed in the lexical environment, this allows for instance to write weird code like (defun ha ()) (flet ((ha () (ha))) (flet ((ha () (ha))) (ha))
16:28:16
shka
jackdaniel: i think that there is nothing to understand, i was trying to be contrarian when i really shouldn't be :P
17:50:21
shka
even if you don't end up defining your own, ability to select what should happen from the debugger is at times such a time saver!
19:49:28
Josh_2
being able to reconnect to a server without losing any state at the time of disconnection is epic
21:44:16
kevingal
Never mind, it's an extension to the slime package, so you just add (push 'slime-asdf slime-contribs) to your Emacs config.
22:57:27
char
scymtym, Bike: I noticed that you changed the license on trivial-with-current-source-form. Any particular reason for that?
23:00:05
scymtym
char: etimmons said they couldn't use the system at work due to the license. are you asking for any particular reason?
23:28:06
kakuhen
silly valley is probably not interested in "stealing" lisp code, and even if they are, they probably want Clojure, not Common Lisp.
1:42:31
char
What is the expected behavior to call a function that has both &optional and &key without providing all optional but providing key?
1:44:29
White_Flame
SBCL even gives you a style warning when you define a function that way, but it's not illegal
1:45:10
White_Flame
just consider that the keywords are in the same &optional scope as your optionals, so yeah in-order fill-in
1:45:46
White_Flame
(the keyword list being one of the optional things, its contents obviously being non-positional)
1:46:45
jcowan_
†IMO use &optional *or* &key, not both. "Entweder transsubstantiation oder consubstantiation but in no case subsubstantiation." --my cousin James
2:02:39
pjb
char: notably in CL there are 2 functions that have both optional and key arguments, and they're a known pitfall.
2:08:20
pjb
write-string, write-line, parse-namestring and there's also a macro: with-output-to-string.
3:15:36
kakuhen
Does anyone know here if there has been an attempt to provide a common lisp interface for Audio Units or VST?
3:40:55
pjb
kakuhen: AFAIK, not. Note that VST 3 API is a C++ API. This makes things more difficult.
3:41:50
pjb
kakuhen: also, VST is designed to make plug-ins, and it's difficult to make a plug-in in CL. You'd have to use ecl, and generate a library, and load libecl.so along.
3:42:26
pjb
kakuhen: clasp which integrates "natively" with C++ would be nice, but I think it lost the ability to generate libraries like ecl can.
3:42:44
kakuhen
but I have a reference book on Core Audio and it's pretty complicated (for me at least)
3:42:52
kakuhen
a lot of basic data structures it uses, I dont know how you'd make the equivalents on Lisp
3:43:12
pjb
kakuhen: one solution would be to implement a VST module that would forward stuff on a socket, and have a CL process connected to do the job. of course, it would then be much less efficient. Perhaps going thru shared memory would be feasible.