freenode/#lisp - IRC Chatlog
Search
7:38:30
joh11
if I called a function foo from the repl that calls another function bar, is there a way, when I recompile bar that foo automatically use the new version ?
7:38:59
pjb
This is not specified by the standard, but of course, one can design an algorithm to include in an implementation to do that.
7:39:21
pjb
Also, have a look at ibcl, you could implement it in an implementation independent way, as an add-on library.
7:39:34
pjb
https://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/ibcl/index.html
7:40:28
pjb
For functions defined in the REPL, this is already the case, it's automatic. Also, functions defined in different compilation units when compiled (usually different files).
7:40:55
joh11
Im just messing with sdl2 and wanted to leave my window opened while coding other stuff, this works with variables but not with functions apparently
7:41:29
pjb
joh11: said otherwise, the called functions are "hardwired" in the caller only when the called function is declared INLINE and not NOTINLINE, or when they're in the same compilation unit.
7:42:02
pjb
joh11: in the other cases, the calls go (semantically) thru the symbol-function, so if you redefine a function, it's taken into account next.
7:42:32
joh11
ok so if I mark foo as NOTINLINE, or place it in another file than bar it should work ?
7:43:21
pjb
If your program design depends on changing the function definition at run-time, do declare it NOTINLINE.
7:44:57
pjb
so about FUNCTION, FDEFINITION, SYMBOL-FUNCTION, the thing is that they return the function object. If you store it somewhere, and redefine the function, then those old function objects are still used.
7:45:22
pjb
This is one important difference between (apply (function foo) args) and (apply (quote foo) args).
7:46:29
pjb
In the first case, the function object is passed, in the second case, the symbol FOO is passed. In the later case the APPLY function will call SYMBOL-FUNCTION itself, so if the definition of FOO has changed, APPLY will use the last fbinding, ie. the redefinition.
7:47:01
pjb
Assume the function or object are not passed directly, but stored somewhere before the call.
7:48:20
pjb
For example, if you play with reader macros: (set-macro-character #\^ 'reader-macro-for-^) is better while developping it and testing it, because just redefining the function is enough for the reader macro to take it into account. With (set-macro-character #\^ #'reader-macro-for-^) you will have to re-evaluate this form each time you modify the function.
7:49:50
pjb
Ie. if you write a HOF (high order function, a function that takes functions as arguments), instead of restricting it to functions (checktype fun function), you should allow function designators (deftype function-designator () `(or function symbol)) (checktype fun function-designator)
7:56:48
joh11
ok so I moved bar to another file but now I have another problem : my (format t "test") are not displayed
8:28:12
pjb
joh11: err, moving to a different file is not necessarily the best option. It makes it implicit. And usually files are used to organize things by module (or by package), rather than on such technicality. It would be better to just (declaim (notinline bar)).
8:28:55
pjb
format t outputs to *standard-output* which may be bound to different streams at different times, and streams can be redirected to various places.
8:31:17
joh11
pbj: yeah but in my case it makes more sense because it is a collision handling function so it is ok to place it elsewhere
8:31:21
pjb
joh11: you may also use STEP to see what functions are called, step by step. In ccl, cl:step is not implemented, so you may use cl-stepper instead. https://groups.google.com/forum/#!search/cl-stepper$20lisp$20informatimago/comp.lang.lisp/nj3jFxcJYM0/QbzGkAbyAtMJ (cd ~/quicklisp/local-projects ; git clone http://github.com/informatimago/lisp informatimago) before quickload.
8:33:08
pjb
good. still consider cl-stepper, it has nice features. (eg. (step (foo) :trace) will prints a trace of all steps. (big output). Happily (or not), cl-stepper works by instrumenting the code, so it only steps the code that has been compiled with cl-stepper instead of cl.
8:34:48
jackdaniel
you may be a meanie and cause a serious distress to most channel participants by ending your sentence with opening parenthesis (
8:34:49
joh11
so I will have to store a variable to the *standard-output* so that it is not shadowed by the sdl stuff ?
8:36:50
pjb
also, say, debugging "traces". There's a *debug-io* but it's for interactive debugging, it may be connected to GUI instead of logs…
8:37:51
pjb
or of course you can (defvar *my-trace-output* *standard-output*) but this would duplicate *trace-output* for no good reason apparently.
8:45:23
makomo
if i have a class and i have functions (instead of methods, because i don't need the genericity) that perform operations on objects of this class
8:46:22
joh11
pbj: ok it works now with a (defvar *my-stream* *trace-output*) but only when I press enter on the repl so not that great. Anyway it was only for debug purposes, I'll use step instead
8:57:26
pjb
STRING-UPCASE is named like that, because it returns an upcased string from the string designator argument.
8:57:58
pjb
For procedures (operators that don't return anything specific, but that have specific side effects), name them after the main side effect.
8:58:28
pjb
Eg. PRINT is called PRINT because it prints stuff. FORMAT is called FORMAT because it formats stuff. READ is called READ because it reads stuff.
8:58:31
makomo
pjb: it's not always that easy :/. this function returns the clock's state (computed as a function of the clock's current cycle)
8:59:05
makomo
yes. what i was aiming for is, whether or not i should use CLOCK- as a prefix all the time for such functions
8:59:40
pjb
joh11: for debugging purposes you can go ahead and use directly *trace-output*. What do you mean only on the REPL? Do you run it otherwise?
9:00:16
pjb
For example, if you have a function that returns the hour from your clock, just call it HOUR. No need for a CLOCK-HOUR with the prefix.
9:01:29
pjb
makomo: but also, it's a question of style and of API. If you define functions for an API (if they're exported from your package) you should think ahead to keey it stable on long term. So if now it's a mere function, it could become a generic function later.
9:01:31
makomo
and if later on you end up with a word that's too vague, you'll have to rename everything else to be consistent
9:02:12
makomo
pjb: yup true. although, for generic functions there's usually no problem, since you have specialization going on
9:04:40
joh11
pjb: nevermind I found the problem. I forgot to specify the stream in (force-output) it was *standard-output* that was flushed, and I had to press enter (or any expr) in the REPL to show it
11:57:13
aeth
A prefix is a good way to handle things (I see it sometimes even for defclass accessors)