freenode/#lisp - IRC Chatlog
Search
21:08:35
emaczen
How much of a speedup can I expect with SBCL if I declaim and declare my functions/methods
21:09:32
jasom
emaczen: generic function calls are not significantly affected by declarations in sbcl, since you are free to add methods at any time
21:11:14
emaczen
I understand that, but I'm pretty content with the relationships amongst my classes -- I would have to rewrite it all without CLOS to get it to be fast??
21:14:00
Bike
you want general advice for optimizing unknown programs? profile and see if you can think of a smarter algorithm for the slow parts
21:14:35
jasom
a non-generic inlined function with an etypecase that calls the actual implementations is *significantly* faster on sbcl than GF dispatch, so if you have small functions, you will be held back by GF dispatch (but as Bike says, profile first, then optimize)
21:22:59
jasom
self% what fraction of samples were in this one; cumul% what fraction of samples were in this one, or ones above it; total% what fraction of samples were either in this one, or this one was on the call-stack
21:29:00
Bike
this is why i said, find better algorithms, rather than doing stuff like declaring types
21:30:46
pjb
Fastest way to remove elements from a list, is not to add them there in the first place.
21:31:15
Bike
pjb, could you please just say what you mean outright rather than waiting for a confused "are you serious" so you can pontificate
21:36:46
aeth
emaczen: At least ime, it's rarely worth doing type declarations if it's not a sequence or a number.
21:37:30
aeth
Sequences can make a huge difference, especially if the type information you give is a known length rather than * length
21:38:27
aeth
(This is SBCL, other implementations might be further behind, but they'll probably catch up eventually.)
21:39:32
aeth
But that's because sequences and arithmetic functions are a special kind of non-CLOS generic function, where type information is very useful.
21:40:33
pjb
flip214: basically, you would have to duplicate the solar system, move the duplicate 3 years behind (about 25,000 light years behind). Then when you want to go back in time, you would have to travel those 25,000 light years very fast…
21:41:06
flip214
pjb: as light has nearly no width, I can fold it up into a hilbert-curve, so I can easily store 3 light years in a container of, say, 2x2x2 m³.
21:41:52
pjb
Sorry, I meant 75,000 light years above. It's incredible, but we're travelling at a speed of 24,194.16 light years each year!
21:43:36
jasom
diffraction effects happen at multiples of the wavelength, and the wavelength of even visible light is on the order of a micron
21:44:52
pjb
Now, it's possible that the orbit of the planets doesn't change plane when we circle around the galaxy center, so the direction depends on the time of the galactic year. I would assume.
21:45:00
jasom
flip214: did you read what that calculation does? It calculates the width of a fluid flowing at a hight of 1 inch, a flow-rate of 8L/min and linear velocity of c
21:46:42
aeth
emaczen: I think the main thing you get from type declarations for most types is type checking at the beginning of the function (in SBCL, actually before the beginning), instead of when you call a function that expects a different type at some point in the middle of the function, e.g. this will prevent "Hello, world!" from showing up: (defun foobar (x) (declare (list x)) (format t "Hello, world!~%") (car x)) (foobar 1)
21:47:47
aeth
(In SBCL the difference with a check-type at the top of a function is that check-type is slightly less efficient, but lets you recover by providing a valid value at runtime)
21:50:50
aeth
emaczen: If you inline things all of the way, with an eventual etypecase or typecase, you will probably see SBCL remove the branches that won't happen (i.e. the other types) automatically. An alternative would be https://github.com/markcox80/specialization-store/ for inline type-based dispatch or https://github.com/guicho271828/inlined-generic-function/ for inline CLOS dispatch
21:51:48
pjb
flip214: there's no sense in giving astronomical distances in other units than light.year. Expressing speeds in light.year/s is also way more meaningful than keeping m/s.
21:53:07
pjb
Actually, even short distances are better expressed relative to light. Eg. your leg is about 3 ns.light long. Way more informative than saying that it's about one yard long.
21:53:33
flip214
pjb: but using the galaxy as zero point is very galacti-centric again. same mistake as, eg., Kopernikus.
21:53:59
pjb
6 ns.light from your feet to your brains means that you cannot feel anything fromr your feet but 6 ns too late.
21:54:23
flip214
pjb: well, within the solar system AE is a nice measure, too. in my youth the parsec was en vogue, but that's changed to light years, yeah.
21:55:47
flip214
pjb: well, you keep your initial system, and I'll use mine. currently I'm at rest, it's nearly 11pm ;)
21:55:58
pjb
Notice also that when parsecs are used, they mostly don't know the radial distances and speed in general. It's a nice unit, but so limited…
21:56:50
pjb
If you want to take it into account, the speed of the Milky Way relative to the Local Group is about 600 km/s.
21:57:11
flip214
what? 1 parsec is defined via the AE, no need for other radial distances or speeds. 1 parsec = 3.262 ly
21:59:05
flip214
pjb: yeah, exactly. but the triangle is defined via the angle 1" and the opposite length of 1 AE.
22:00:16
pjb
For example, sending a modulated laser beam thru space to a reflector. So when you need an old value, you can read it back frmo the beam.
22:00:40
aeth
The #1 performance improvement I can normally get is by preallocating before loops rather than heavily consing during the loops.
22:00:55
rjmacready
is there any common lisp implemented in a common lisp based on the special forms alone? http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm
22:01:02
aeth
e.g. allocating 4 vectors that are constantly overwritten each iteration rather than allocating 4 new vectors each iteration
22:01:22
jasom
rjmacready: that's not possible; how do you implement "print" only in terms of special forms?
22:01:33
pjb
rjmacready: not really. First special operators are not all the primitives of a CL system. Some functions are primitive too!
22:02:07
pjb
rjmacready: otherwise you may have a look at cl-stepper, which redefines special operators as macros to implement a stepper.
22:03:17
rjmacready
jasom: yeah i was looking at that and wondered there was some special form only based implementation
22:04:19
aeth
rjmacready: You can probably implement CL without CLOS and without most of loop. Some of loop really is just too convenient for macros, especially collect but sometimes also append. (Most of loop has alternatives, those don't really.)
22:04:58
jasom
implementing collect and append is fairly easy, you just need to keep track of your tail pointer
22:05:04
aeth
So I just picked two of the easiest complicated parts of the language to remove, and then said you can't remove them. :-p
22:06:59
aeth
jasom: I guess my point is that most of the common useful parts of loop have direct equivalents in dofoo or higher order functions, but not collect and append, you'd essentially have to write something lower-level in do
22:07:09
rjmacready
had this silly idea of plugging an empty executable as inferior lisp to slime and checking what would arrive there
22:07:20
emaczen
I really do need to go back and look through my code, usually I am not too concerned about speed
22:07:21
pjb
Also, the usefulness of most of special operators to implement a language is rather dubious. eg. THE is useless.
22:08:13
Bike
there's also a question of how you're like, implementing this. sbcl and sicl and stuff work on a principle of having an existing lisp just dump compiled files, so it's not like you're bootstrapping up from some limited set of operators
22:08:32
pjb
It can be implemented conformingly as (defmacro the (type expression) (declare (ignore type)) expression)
22:08:39
aeth
pjb: Determine the return type of a function in a compilation unit, and be as specific as possible. Wrap calls to it within that compilation unit with a the (assuming sbcl semantics, which type-checks and uses truly-the for real assumptions)
22:11:36
aeth
(I actually suspect SBCL binaries could be made much more efficient if everything's moved into one compilation unit as the final compilation process, to keep literally all of the program's type information and really put all that inference to work)
22:16:18
aeth
Bike: I suspect the main use for a very restricted Lisp to implement Lisp would be to build something that's useful for building a richer, probably better written Lisp.
22:20:11
aeth
Can you use SBCL to cross-compile SBCL to other architectures? e.g. new architectures?
22:21:01
pjb
The only usefulness in a restricted lisp, would be either you time travel to 1958, or you get lost light years from Earth without a CL implementation.
22:21:40
aeth
I *guess* a restricted Lisp might be more secure, but then you'd probably just want to write a VM and use bytecode, not a subset of Lisp.
22:21:41
pjb
In all other cases, you can get access to a CL implementation faster, and use it to implement faster and easier your new CL.
22:29:00
aeth
I've skimmed through the Lisp Machine Manuals and they're very similar to the HyperSpec
22:31:54
Shinmera
https://en.wikipedia.org/wiki/Kyoto_Common_Lisp "KCL is notable in that it was implemented from scratch, outside of the standard committee, solely on the basis of the specification. It was one of the first Common Lisp implementations ever, and exposed a number of holes and mistakes in the specification that had gone unnoticed."
22:34:48
Bike
well, beach's method has proven to be pretty performant and is conceptually pretty simple, so you could do that.
22:37:21
aeth
White_Flame: I'd assume that the main thing that would matter for the runtime performance of CLOS is dispatch
22:38:13
Bike
the rest of clos is basically just data structures, and some functions you ahve to call sometimes
22:39:02
White_Flame
well, there's also instantiation & registration, updating classes, etc, that can have their own performance impact
22:39:29
aeth
If CLOS generics were as performant when the class is known as the generic functions for arithmetics and sequences are when the types are known, that would completely change how people write fast CL. Although type-dispatch would still be necessary for numbers and sequences a lot of the time.
22:40:07
aeth
Would it be possible to just JIT the dispatch in an otherwise AOT implementation? JIT has big drawbacks, too.
22:41:24
White_Flame
and so because it's a single centralized dispatch function, it can't take advantage of call-site knowledge
22:42:05
aeth
I wonder how hard it would be to unify type dispatch (e.g. specialization-store) and class dispatch. If that's even possible.
22:42:47
aeth
What I like about what specialization-store does with types is... it produces the exact same thing that I'd produce by hand. Except automatically.
22:42:47
Bike
they're the same concept, it's just that clos allows things to be redefined, inhibiting static analysis
22:43:53
White_Flame
yeah, it'd be nice if you could say "bake these things in" at some point, and "unbake back to dynamic, I want to change things"
22:44:28
Bike
it would, but unbaking would require recompiling all call sites in general, which is kind of annoying
22:44:48
aeth
White_Flame: There are, I think, essentially three levels of control. Inline, inline function call (remove the generic dispatch, keep the function), and runtime dispatch. Specialization-store handles all three of these for type-based dispatch.
22:44:54
Bike
i should probably do that, actually, i k now all the bullshit in clos well enough by now
22:45:55
aeth
Although I'm not sure if specialization-store keeps the return type information when there's an inline function call, which would be useful. That information is lost in SBCL if it's outside of the compilation unit (normally the file)
22:51:37
aeth
It looks like speicalization-store does keep the return type information when doing a named specialization. (defspecialization (foo :name %foo/single-float) ((x single-float) (y single-float)) single-float (+ x y)) (defun foobar () (+ 1f0 (foo 2f0 3f0))) ; does not have a generic + in SBCL
22:52:32
aeth
I'd love to see something just as mature for optimizing CLOS, especially if it was compatible.
22:55:27
aeth
One thing that I'm considering doing soon is using structs and CLOS to define custom data structures. In particular, I think typed lists expressed as structs would be very useful, especially for what I'm doing. At the moment, if something's best expressed as a linked list, I have to type check multiple times where a typed data structure would just type check the elements once, when making the list, and then I'd just type check the list itse
22:56:53
aeth
So what I'm considering writing is: a cons cell represented as a struct with a car and a cdr, where the car is some type and the cdr is either null or another of the new type of cons cell
22:57:25
aeth
This is not entirely portable, but where it isn't portable I can add manual type-checking with #+foo for the implementations that don't check on e.g. creation or access
23:10:27
scymtym
pkhuong made (in 2007 no less) a prototype for "sealed" generic functions which would inline dispatch and/or methods and derive call site-specific return types depending on availability of argument type information and declarations
23:13:19
aeth
I'm only aware of https://github.com/markcox80/specialization-store/ for writing +-style and map-style type-generic functions and https://github.com/guicho271828/inlined-generic-function/ for inlining CLOS dispatch, although I haven't tried the latter, and wouldn't be able to use it in my MIT-licensed projects because it's LLGPL, which would complicate using my projects.
23:22:29
jasom
hmm, mop should give me enough information to automate what I currently do when GF is too high
23:27:58
aeth
Hmm... How does CLOS handle a generic with two methods: parent-class child-class and child-class parent-class when called with child-class child-class?
23:29:42
aeth
Looks like it calls the child parent one, which makes sense. The most specific for the first argument.
23:33:25
specbot
Standard Method Combination: http://www.lispworks.com/reference/HyperSpec/Body/07_ffb.htm
23:33:53
aeth
Where do people tend to use methods in their code? I generally only use them when using someone's CLOS-based API that expects inheritance and methods. For my own code, things are usually very specific and functions make the most sense.
23:35:21
jasom
aeth: they are often used any time dispatching based on classes or symbols is wanted; also :around can be useful in some cases even when there is only a single class involved.
23:35:49
jasom
aeth: consider if you wanted something similar to print-object; generic functions are the most obvious solution
23:36:46
aeth
I normally use objects (CLOS and struct objects) just to store data to prevent things like e.g. a function call with 14 arguments (this has happened to me before)
23:37:32
aeth
I normally decide between CLOS and structs by using structs (or arrays!) for things that are simple, efficient, and typed and CLOS for the rest.
23:37:38
Bike
to "bake" a gf you might have to account for the possibility of new classes that inherit from multiple specializers. kind of a combinatorial explosion. however, the set of possible effective methods is probably quite limited in most cases
23:38:59
jasom
I use CLOS and structs all the time; I often don't want the fancy stuff that objects give me, and I can still specialize on the class of the struct
23:39:51
aeth
A struct is great for something like a queue (which in turn is just a specialized array with a handful of extra things, thrown in a struct).
23:41:30
aeth
Bike: yeah, that's the correct term, I'm just not sure if it would confuse people or not
23:42:01
aeth
jasom: Well, you can implement a queue as a list or an array. Arrays seem to win for what I tend to do.
23:42:21
aeth
Since CL doesn't have typed lists built in, arrays often win for things where lists *should* win inutitively!
23:42:27
Bike
multiple inheritance, redefinition semantics, and slot-value/boundp/etc are the only differences between standard-class and structure-class, i think
23:43:18
aeth
Bike: One thing I'd love to see is structures without any inheritance at all. I'm not sure if this can be added as an extension to the language. This would, afaik, be all that's necessary to support arrays-of-structs.
23:44:01
jasom
does :include enforce that the newly created class is a subtype of the included class?
23:44:32
aeth
Bike: one thing I've found out about the Internet is that the best way to get the correct answer is to state the wrong answer and be corrected. :-p
23:44:52
Bike
in the same way ub8 is a subtype of ub16, but they can have distinct upgraded array types
23:45:25
jasom
"it becomes a subtype of the included structure." <-- good to know; the spec doesn't always do what I want, but does here.
23:48:55
jasom
An actually useful equal would be like equalp, but one uses eql to compare characters. Perhaps uses a GF for comparing other objects as well.
23:53:01
aeth
Someone should make a list of all of the extensions (current and not yet implemented) that modern CL needs to be maximally efficient. It would probably be most useful if they're listed as the portability libraries, like https://github.com/Bike/introspect-environment
23:53:46
aeth
just a simple table "portability library over extension" and "implementation" with "Yes"/"No"/"Partial"/"Unknown" as values in the cells
23:54:57
Bike
introspect environment isn't either, it's just a bit helpful for some efficiency things
23:55:34
aeth
Bike: introspect-environment is the thing needed by some libraries that make things efficient, so it would go on the list rather than (or in addition to?) those libraries
23:56:11
aeth
(I suppose those libraries could go on the list too, with "Partial" if they have to work around the lack of introspect-environment)
23:58:16
aeth
although thanks to macros and turing completeness, just about anything can be implemented in just about any CL, just not necessarily efficiently, afaik.
23:59:07
aeth
Bike: I think listing portability libraries over language extensions that are actually in use is considerably more useful than proposing language extensions to implementations.
0:14:04
AeroNotix
aeth: I've brought this up in here once or twice before. Biggest consensus is that there's no need to make further language/standard changes as everything realistically can be plonked in a library
0:16:44
aeth
AeroNotix: Some libraries require implementation support for an efficient implementation (or any implementation at all), though.
0:17:58
aeth
AeroNotix: well, I'd say unicode characters/strings are an interesting and widely applicable feature that needs implementation support
0:18:53
aeth
It's very important to support Unicode so that you can use Emoji. (You also can use Unicode for non-English languages!)
0:18:53
jasom
aeth: that reminds me, I need to portabilify the sb-unicode package; it is almost indep already and provides a lot of unicode features that are really useful.
0:23:15
aeth
There's also a very trivial portability library (possibly already written several times over) that could be useful for other things that languages implemented in CL could use, such as float-nan-p (and the ability to get NaN at all, for languages where you can write a literal NaN, such as modern Scheme... that's one place where I fail r7rs conformance tests)
0:44:24
emaczen
aeth: Wait I can enable inline-generic-functions just by pushing it onto *features*?
0:49:34
aeth
And unfortunately the library is LLGPL, which could complicate building standalone binaries because then you'd be entering unknown legal territory.
0:52:30
aeth
The LLGPL is a preamble to the LGPL with Lisp-specific "clarifications" that may or may not be a good idea, but it effectively becomes a custom license that's neither FSF nor OSI approved. It would be clearer just to use LGPL, but that would essentially unambiguously forbid standalone all-in-one binaries, then, afaik.
0:54:43
aeth
The older the library, the more likely it is to use the LLGPL, which imo is the worst thing to happen to the Lisp ecosystem. I am not a lawyer, but your lawyer might say do not use custom FOSS licenses. And, really, imo any situation where "talk to a lawyer" somehow becomes part of using a library is a bad thing, no matter what the lawyer winds up saying.
0:56:42
aeth
The FSF's official position is "the LGPL works as intended with all known programming languages" https://www.gnu.org/licenses/lgpl-java.html
0:57:28
aeth
And the FSF definitely knows about Lisp. There are two GNU Common Lisps (CLISP, GCL) and at least three GNU Schemes (Guile, Kawa, MIT).
1:04:00
aeth
Imo, for libraries use a permissive license unless you only want (A)GPLed software to use it. For applications, choosing between copyleft and permissive is your choice, depending on what you want. Copyleft is most useful for large, nontrivial applications if you're concerned about a commerical fork (or, if you require copyright assignment, you can sell exceptions for commerical software and be the only permitted commerical fork... this is t
1:05:22
aeth
The GPL does not prevent freeloading commercial forks, though. e.g. Oracle Linux is a fork of Red Hat Enterprise Linux.
1:08:42
aeth
The LGPL (not the LLGPL please!) is another option for libraries, but until someone gets clarification from the FSF (I think they have an email for this sort of thing), afaik the best we have to go off of is the Java LGPL article, where it says that JAR-based distribution for libraries is okay under the LGPL. Thus, it looks like the LGPL could prevent distrubtion of Lisp apps that put everything in one binary.
1:10:28
aeth
The only Lisp executables I'm aware of are the web browser written by jmercouris and some games produced by the #lispgames community.
1:11:08
emaczen
aeth: What do you call the file that is produced with (sb-ext:save-lisp-and-die ...)
1:19:46
jasom
emaczen: save-lisp-and-die makes an image; it's also an executable if :executable t is passed.
1:25:28
aeth
Afaik, an alternative would be to distribute SBCL to end users, like Sun did and Oracle does with Java.
3:53:37
pragmaticmonkey
Is there a lisp like language that isn't a global bucket of whackly named functions? Something with a lil better package and scopes?
4:58:30
jmercouris
What are you guys working on right now? Anyone interested in sharing their lisp projects?
5:03:25
minion
jmercouris: SICL: SICL is a (perhaps futile) attempt to re-implement Common Lisp from scratch, hopefully using improved programming and bootstrapping techniques. See https://github.com/robert-strandh/SICL
5:03:32
minion
jmercouris: Cleavir: A project to create an implementation-independent compilation framework for Common Lisp. Currently Cleavir is part of SICL, but that might change in the future
5:04:56
minion
There are multiple help modules. Try ``/msg minion help kind'', where kind is one of: "lookups", "helping others", "adding terms", "aliasing terms", "forgetting", "memos", "avoiding memos", "nicknames", "goodies", "eliza", "advice", "apropos", "acronyms".
5:05:07
minion
To add a term, say something like ``minion: add "term" as: the definition''. I will remember the definition.
5:05:40
ahungry
This isn't Common Lisp, but it's in the lisp family and probably has some overlap with CL user's tooling (Emacs), new mode I just finished an mvp of: https://github.com/ahungry/redditor-mode
5:07:02
jmercouris
beach: The difference between cleavir and sicl isn't exactly so "clear cut" to me
5:08:22
beach
jmercouris: Cleavir is a compiler that can be used by any implementation that so wishes.
5:10:23
jmercouris
Without using vendor specific extensions, are there enough functions and accessors to persist a lisp image?
5:10:33
beach
Most Common Lisp compilers could be characterized like that. The specificity of Cleavir is that it can be customized to the specific representations and data structures of any Common Lisp implementation.
5:11:15
jmercouris
it doesn't just use the functions, data types, and accessors defined in the lisp standard
5:11:24
beach
Customized. By the use of methods and subclasses. Just like any other CLOS-based software.
5:13:10
beach
Cleavir turns those details into generic functions and classes that can be altered by the implementation, using subclassing and methods.
5:14:55
jmercouris
I think that would be THE killer feature to convince an implementation to port Cleavir
5:15:18
beach
For SICL, the plan is to stick most of the system in a shared library, so that small executables can be produced for those who are obsessed about that.
5:15:24
jmercouris
I've obviously thought way less about this than you, but that's just an outsider perspective
5:16:55
beach
Either way, that feature is related to the implementation, so Cleavir can't do anything about it.
5:17:49
beach
A thing like that would be VERY implementation specific. I see no way to make it generic.
5:17:51
jmercouris
I guess your goals are more research oriented than anything, so I imagine it doesn't really interst you
5:18:31
beach
I have no interest in digging into the details of every free Common Lisp implementation if that is what you mean.
5:18:47
jmercouris
again, a standard "way" of bundling for the end user, and then handling the implementation specific details
5:19:38
beach
I have absolutely no idea how to even think about creating such a thing, other than a generic function CREATE-BINARY that each implementation would have to define a method on.
5:20:19
jmercouris
you would define those methods like +sbcl... etc, and then a user can just say (create-binary :with-name "binary-name" ...)
5:21:43
beach
The top 5 will last my remaining lifetime, so I don't often look further down the list.
5:31:27
beach
The other thing about Cleavir is that it uses the full Common Lisp language in order for the code to be maintainable and modular. Whereas for instance the SBCL compiler does not use generic functions, because it is needed when CLOS is not available. This fact makes the SBCL compiler much harder to maintain.
5:32:18
beach
Same thing with SICL, it uses the full Common Lisp language to implement most of its features. So for instance SICL LOOP uses generic functions and classes in its expansion code.
5:38:11
beach
There are very few people that have the required knowledge and that are also available for work. But when I find one, I'll consider this option.
5:39:23
jmercouris
And when you train one, they can train another, and then bam, exponential knowledge share
5:39:45
jmercouris
sure, there are losses the further from the source, but if everything is well documented, mistakes can be corrected
5:41:02
beach
I can't afford to pay someone for full-time work. And I certainly can't afford the typical fees in the US or western EU.
5:41:33
jmercouris
but if you made a business case for your work, you could secure a grant, or investment money
5:42:30
jmercouris
I'll give you this, you are possibly the best Lisp coder in existence right now, but I don't think you know anything about business
5:43:01
jmercouris
If you care about the completion of your project, you'd give it a really good hard think
5:43:56
beach
One thing I don't like is when people put words in my mouth. I don't care about the completion of my project enough to manage a business.
5:44:18
jmercouris
beach: You don't care about the completion of your project that you work on every day?
5:45:09
jmercouris
Furthermore, if you don't care about completion, why would you have thought about paying developers?
5:45:27
beach
jmercouris: I am a researcher. I get partial results as my papers show. Clasp has already implemented fast generic function dispatch and it uses Cleavir. That's good enough for me.
5:47:06
jmercouris
I don't mean to upset or anything, if I am bothering you, tell me and I will stop, I just enjoy controversial topics
5:47:17
jmercouris
to see if I can learn something, or understand how you think, so I say provocative things
5:48:23
beach
I would like to see my numerous projects finished, of course. But that is not my highest priority, and if the cost of getting there is too high, then it just won't happen.
5:48:51
beach
Part of the reason it is not high priority is that very few people care about my projects anyway.
5:52:32
beach
Sure, and I do my part, not only for computing, but also for the environment, for the economy, etc. But I am quite pessimistic about the future. But that's off topic.
5:53:09
jmercouris
So, if I understand, you think the impact of your projects is not significant enough based on a proxy measure of overall interest?
5:53:37
jmercouris
And since this is not inline with your goal of bettering the world, why invest oneself fully into it?
5:55:10
jmercouris
So you are satisfied with the amount of positive impact you currently produce, and therefore there is no need to necessarily complete your projects?
5:56:03
beach
My current strategy is to extract some "modules" from SICL and Cleavir (and other projects) to independent repositories, and to write tests and documentation for them.
6:11:03
stylewarning
beach, I might be down to (co?)sponsor a student to help implement some of your research
7:47:01
aeth
beach: Is there any chance that your fast CLOS will one day replace PCL in implementations like SBCL? (I assume that you either already beat its performance or will eventually.) I'm not sure anyone on the planet knows more about CLOS than you.