freenode/#lisp - IRC Chatlog
Search
18:03:27
ecraven
which part of the CLHS should I look at to understand when a redefinition of a function is allowed? (interactively via SLIME on a running image)
18:04:45
anamorphic
genhash and annoyingly register-test-designator throws an error if a designator is already registered. Is there any reason why it couldn't provide a restart? I know it's a CDR2 an all, so had wondered if it's a spec thing
18:08:27
ecraven
well, can I just redefine existing any function in any package at any time, and it will work?
18:10:53
djeis[m]
On some implementations redefining functions in the CL packages triggers an error, and by the spec the consequences of those redefinitions are undefined. Otherwise, technically, yes.
18:11:25
ecraven
so if an implementation inlines some functions, it has to take care to recompile everything depending on a function if it is redefined?
18:12:36
djeis[m]
And those functions still can be redefined, you just have to recompile everything which uses those functions for the update to propogate.
18:13:34
djeis[m]
It's a bit of a pedantic distinction, but I'd say an important one- redefinition means something very specific in the case of functions, and it doesn't include things like inlined functions.
18:14:38
djeis[m]
The same thing is true of macros, really- if you redefine a macro you still have to recompile everything which uses the macro.
18:16:40
djeis[m]
Another place where that shows up is when you use 'func vs #'func. Redefinition updates the symbol, so if you call 'func it'll get updated. #'func, on the other hand, captures the actual function object and that does not get modified in-place.
18:28:14
p_l
Automatic recompile of inlining functions requires a who-calls database and most implementations don't provide one
19:19:52
stylewarning
I would be fearful of re-compiling functions I didn’t explicitly ask for, esp. if I’m developing them.
19:20:54
specbot
Constraints on the COMMON-LISP Package for Conforming Programs: http://www.lispworks.com/reference/HyperSpec/Body/11_abab.htm
19:24:43
|3b|
and redefining a function generally won't affect any running instances of that function (including those waiting on a call to some other function)
19:27:19
|3b|
also unspecified when standard functions look up function bindings from symbols, so a running (mapcar 'foo ...) might see a redefined FOO on next iteration, or not at all. next call to (mapcar 'foo ...) would see new definition though
19:28:32
|3b|
(and i doubt most user functions specify that either, but probably tend to do the lazy thing and let funcall resolve it so would see redefinitions)
19:32:31
on_ion
stylewarning: i may have been thinking of JIT in general; ie. in julia if you call a function for specialized types that has not been yet required/compiled, it will do so
19:39:34
jcowan
The question is, are running functions decompiled when they are changed out from under you?
19:54:23
on_ion
ah. julia keeps around generic versions and type-dispatched versions and etc., likely it would have the least-optimized version as the most generic
19:58:53
jcowan
explains how the Graal compiler (the latest JIT engine in Oracle JVM) dynamically deoptimizes code when its assumptions are violated.
20:00:12
jcowan
The primordial JIT (HP APL, 1977) already did this, first assuming that the rank and shape of all variables was fixed, and checking this at the beginning of a line of APL. If the assumptions were false, it deoptimized the code to assume only rank constancy, and then recompiled only if a variable changed rank (which hardly ever happens)
0:42:26
fiddlerwoaroof
I've done a bit of Haskell and work with people who write production Haskell apps
0:42:46
stylewarning
I ask because I'm wondering what folks would find convenient as an interoperable representation in Lisp.
0:43:45
stylewarning
in the sense that if you were to define an ADT in, say, Haskell, and you wanted to work with a representation of that in Lisp
0:45:28
fiddlerwoaroof
I personally prefer subclassing to model the things that Haskell/etc. uses ADTs for
0:46:13
fiddlerwoaroof
Because Haskell is built around a "closed world" assumption: its type system assumes that all the relevant types are known at compile-time
0:47:52
stylewarning
Bike: that's what I do in CL-ADT, but it has been inconvenient for re-definition, and inconvenient for creating constants
0:48:17
White_Flame
instead of symbols and simple-vectors, if you used symbol and cons type specifiers, along with OR or MEMBER types, wouldn't that cover most the bases?
0:49:04
stylewarning
Bike: Well it's not so bad, but I haven't been able to guarantee EQ-constness with structs
0:49:25
White_Flame
the most glaring (and recurring) problem with simple-vectors is that their element type is locked to T
0:50:17
fiddlerwoaroof
e.g. make None a singleton and return the single value whenever a None is constructed?
0:50:36
stylewarning
anyway the reason I ask is because i finally decided to cut all the nonsense out and take the plunge of implementing a strictly typed DSL in lisp with a focus on interoperability/incremental development
0:51:03
stylewarning
but I guess I don't know well enough all the nuance about compile-time load-time etc etc
0:53:16
stylewarning
fiddlerwoaroof: my motivation isn't really to implement a whole new language; it's more to allow one to write statically typed and statically inferred pieces of Lisp code, in a way that isn't completely hermetically sealed off from the rest of your lisp program
0:53:37
stylewarning
(e.g., to allow one to write safety-critical portions of their lisp programs in this DSL)
0:54:05
fiddlerwoaroof
Yeah, I've been wanting that too. But the main benefit of types, for me at least, is _not_ the correctness guarantees
0:54:46
fiddlerwoaroof
It's that, in a language with bidirectional type inference, you can use the types as a way to do some kinds of metaprogramming that is impossible with macros
0:55:38
stylewarning
for me, where a lot of my job is writing compilers, the safety is what i care about a lot, because compilers are big and complicated and bugs are hard to find
0:56:49
stylewarning
anyway, I have code here. It's not really functional. Maybe another weekend or two it will be a good enough MVP. Type inference works, type definitions almost work, compilation almost works, etc. https://github.com/tarballs-are-good/coalton
0:58:20
stylewarning
you can see some pedestrian examples of what does work now here: https://www.irccloud.com/pastebin/2CzwH3Iw/
1:01:56
fiddlerwoaroof
The Type Systems as Macros paper that hackett is based on is the most interesting one to me because it seems to lead to an interesting part of the design space
1:02:29
LdBeth
fiddlerwoaroof (IRC): Then the book Partial Evaluation and Automatic Program Generation is a good start
1:02:33
fiddlerwoaroof
Where, since macroexpansion and type checking are interleaved, you can do interesting code-generation things
1:03:07
stylewarning
idk, maybe. I think there's a lot of pay dirt in thinking about things with a very Common Lispy philosophy of building something useful and practical even if a bit muddy, instead of some new-fangled philosophy of program construction.