freenode/#lisp - IRC Chatlog
Search
14:41:14
Xach
I think it would be *great* to have reliable clean unloading of projects! I just don't see how that destination could be reached.
14:42:24
jackdaniel
Xach: in principle ECL could unload fasls which are .so objects underneath. that said devil would probably be in details
14:44:09
Bike
side effects from them would still remain though, right? you'd have to restrict what code you can have in libraries.
14:45:08
jackdaniel
yes. also there are gotchas like: module defines a class, you create an instance of this class
14:48:56
dlowe
if you had a dependency graph, you could require that all dependant modules be unloaded
14:53:34
Xach
I am worried about the thinking traps of "that would be hard to do in Common Lisp so it must not be worthwhile" or "if it were worthwhile to do someone would have done it already"
14:54:25
dlowe
A true rollback could look like moving all objects into the permanent heap and then saving the top of the permanent heap.
14:57:12
Bike
maybe you could just have unloading (assuming no major side effects not covered by def-whatever) mean everything becomes collectable normally, so basically just deleting the packages
14:59:52
beach
I think first-class global environments would be a solution, but we have not packaged them up in a way that they can be used by any implementation or any applications.
15:01:44
dlowe
beach: I was thinking about that, but to get data out of them may involve pulling a lot of other things
15:17:31
pjb
Unloading systems could be achieved if loading systems didn't mutate the global state other than creating new packages.
15:18:06
pjb
and otherwise, undoable mutations. (eg. adding a system object to a list of loaded systems).
15:23:04
selwyn
some common lisp implementations are designed with speed in mind, others with a view to extensions to FFIs in languages like java or c++
15:24:23
selwyn
my question is: has anyone attempted to produce a common lisp implementation which has the aim of being as ansi-compliant as possible as the primary aim above all others
15:25:28
selwyn
(this is not meant as a comment on ansi-compliance of CL implementations around today)
15:42:38
selwyn
beach: i ask because i thought that such an implementation would be of great utility to those who value correct program behaviour higher than execution speed
15:45:05
jackdaniel
otherwise expt would be defined (defun expt (x y) 42), incorrect but insanely fast
15:47:04
selwyn
yeah after i ask i realise that a speed improvement that breaks compliance would probably not be very wise, useful or popular
15:48:13
pfdietz
What you may be asking for is an implementation that strongly rejects programs that have behaviors that aren't specified or defined by the standard. But this would mean you couldn't use pathnames (for example), as they are poorly specified.
15:53:51
sjl_
It could be nice to have a CL implementation that took as many liberties as possible while still adhering to the standard, e.g. where (/= (char-code #\b) (1+ (char-code #\a))
15:54:48
sjl_
Such a HellCL could be useful to run your unit tests, to see if you're relying on anything not-standard-but-happens-to-work-in-most-implementations
15:55:24
Xach
sjl_: I was thinking about the opposite, codifying common practices like that in a test suite or something.
15:58:48
Xach
sjl_: i mean stuff like unicode code points for char-code/code-char, (unsigned-byte 8) arrays reading and writing as you'd expect
16:05:55
sjl_
Oh, so you could run the suite in a new implementation and get advance warning of pitfalls to watch out for?
16:06:07
sjl_
Yeah, that would be useful too. And way less work than making a full implementation of CL.
16:08:33
sjl_
predicates returning random stuff other than t for true cases would be another fun one.
16:12:30
p_l
sjl_: actually, ECL compiled with certain options on one of them *should* fail (= (char-code #
16:14:34
sjl_
but I'm sure there something like (position t (mapcar #'stringp '(a b "c"))) out there in the wild somewhere
16:15:09
sjl_
Josh_2: they return a "generalized boolean", which is either NIL (false) or anything-thats-not-NIL (true)
16:16:26
p_l
at the very least all standard library functions that want predicates accept a generalized boolean
16:18:21
sjl_
(when (eql (stringp a) (stringp b)) (print "a and b are both strings, or both not strings"))
16:21:04
sjl_
or perhaps a slightly-less-arbitrary way to implement stringp with non-eql results: (defun stringp (o) (if (typep o 'string) o nil))
18:45:20
aeth
I seem to rely on booleans (rather than generalized booleans) in two cases: (1) I'm storing something so the general boolean value would just be unwanted noise, e.g. something with :type boolean in e.g. a struct; or (2) I need to make a distinction past just having true/false, so e.g. keywords and t and nil all have some meaning in the API.
18:46:06
aeth
(for the second one, consider an API where t is default, nil disables it, and the keywords are niche alternate behaviors)
18:47:08
aeth
Neither are the return values, though. They're input values. And that's in the standard, too, e.g. with FORMAT. Generalized booleans are too useful in return values because you never know if the caller wants to use the extra information or not and that saves an extra return value.
18:49:19
aeth
Similarly, I also always return nil (or, more rarely, t) even if the function is only used for its side effects. Some do (values) but that might break code that uses certain multiple-value functions/macros (and everywhere else it just inserts a NIL return value)
18:51:45
aeth
Bike: Well, I mean, you could be using multiple-value-call to call a function that has the mistaken assumption that every function returns at least one value, which isn't true for those extremely rare functions that end in (values)
18:52:57
aeth
It sounds like it would never happen, but that's exactly the sort of thing that if it did happen someone will lose a day or two on it because no one thinks it would happen
18:53:11
pjb
aeth: also, it's good to use T/NIL instead of generalized boolean to give the garbage collector an opportunity to do some work.
18:54:52
aeth
pjb: Which means that it's "perfectly safe" (in a reasonable implementation) to return a fixnum or single-float or other, similar things that (probably) aren't boxed.
18:56:26
aeth
pjb: If you're talking about storing, then, yes, definitely, t/nil helps with the GC always. You don't want to accidentally refer to some hash-table of 40,000 elements that could have been collected hours ago if you didn't store a reference to it instead of t
19:44:50
Bike
ecl has some code to make things like (error '(or type-error simple-condition) ...) work. does anybody use such a thing? https://gitlab.com/embeddable-common-lisp/ecl/commit/c6e419101400ee5d4372d748f646011b1480d0a2
19:47:24
Bike
well, clhs says make-condition's first argument is a subtype of condition, so i guess it could be understood as standard
19:47:26
pjb
Bike: it looks like it's conforming! type---a type specifier (for a subtype of condition).
19:48:55
Bike
no, i mean the function ERROR takes a condition designator, and a condition designator is either a symbol or a format control or a condition.
19:49:02
pjb
Bike: error takes a condition n. 1. an object which represents a situation---usually, but not necessarily, during signaling. 2. an object of type condition.
19:49:39
Bike
yes and the designators are clearly defined in 9.1.2.1 and specify a symbol, not any subtype. okay? okay. so does anyone actually use this thing.
19:49:58
pjb
This is a great find! I've been definining conditions just to mix simple-condition with my errors!!!
19:50:43
Bike
well if you did (make-condition '(and my-error simple-condition) ...) that could still just be an empty type.
19:51:22
Bike
it's also in clasp, which is why i'm asking. dunno about others but i sorta doubt it. i'll check sbcl.
19:52:05
pjb
Bike: you're right about 9.1.2.1, but ERROR is specified to accept and OR type specifier, and MAKE-CONDITION is explicitely designed to accept it.
19:53:08
aeth
Tangentially related, but I'd say the weakest part of the standard is conditions. Didn't someone here write their own destructuring-bind just to get a consistent cross-implementation condition there?
19:53:46
pjb
Bike: error is specified to take a designator to a condition (glossary) with a very large definition.
21:58:17
t58
Hey I'm using slime with emacs is there a shortcut to close all the open parens? I'm sure there was one like C-c C-q or something like that but I can't find any reference to it online.
22:17:43
White_Flame
and paredit is highly recommended, nearly always keeping things balanced (except for cut'n'paste)