search

fare / lisp-interface-library

LIL: abstract interfaces and supporting concrete data-structures in Common Lisp
145 stars 17 forks source link

TODO in github issues rather than in TODO file? #10

Closed guicho271828 closed 8 years ago

fare commented 8 years ago

Well, I'm currently in passive maintenance mode rather than active. That is unlikely to change unless I find a work environment where I'm paid to write and use CL.

Now, if you or someone else is ready to take over leadership of lil, I'm willing to help...

guicho271828 commented 8 years ago

sure. I am under gov funding for at least 2 years, and I will be active. I am watching several projects that are trying to be as minimally viable as C++/STL, like in https://github.com/cosmos72/cl-parametric-types , https://github.com/show-matz/CL-STL .

guicho271828 commented 8 years ago

well, I should at least work a bit longer on my local fork.

fare commented 8 years ago

I believe that lil has for it its automatic transformations and a model that fits well with CLOS. On the other hand, its code base is small, the data structures already implemented only cover a small part of the design space, and there should be more macro infrastructure and much more documentation.

guicho271828 commented 8 years ago

The latter half of LIL paper (as well as your intention) seems to be focused on that pure/stateful transformation, but in a practical viewpoint it does not seem much important to me. What I want is a parametric types with a good design. And more data-structure implementations. With a consistent, reliable interface.

And a speed. I plan to plug my CLOS-inlining hacks to LIL and see how fast it can be. Well at least I should start from a benchmark library.

By the way, how extensively was LIL used in ITA? This library needs a bit more credibility that it is actually practical.

It is said that the library problem in CL is gone, but I think it is not true because of the lack of go-to data-structure library. They all seem either a slow, clean hack or a dirty, fast hack.

fare commented 8 years ago

I believe that the pure/stateful transformation is a symptom that the library has a good basic design, even if you don't use it much.

I also wanted more data-structure implementations based on that solid design. I never got around to making lil half as rich as I wanted. On the other hand, I was pleased to see it used for things I didn't anticipated (the monad library).

Speed-wise, I believe that LIL isn't particularly fast. Hopefully CLOS inlining can make it less slow, but still it won't be as fast as dedicated defstructs in each case. It is on the other hand much more flexible. And existing data structure have the correct asymptotic behavior.

LIL was not extensively used at ITA. By the time I introduced it, project QRes was already sick, and though I used LIL in a branch, it wasn't deployed in production. The initial motivation of LIL and its primary intended purpose, was to provide a systematic mechanism for making our code more modular for use with multiple airlines. (The original idea must have been in 2009 or so.) The data structures were a good exercise in proving the feasibility of the approach to combining parametric polymorphism and ad hoc polymorphism. (They were implemented in 2012.) That much needed functional maps thus became available was a happy side-effect. Unhappily the project was eventually canceled before a second production customer was finalized, so the design was in vain. My failure was to be too slow from idea to implementation.

fare commented 8 years ago

This is a clean hack. I fear it is on the slower side. But I hope it is fast enough for most people.

One advantage of the LIL approach is that where you find a performance bottleneck, you should be able to substitute a fast implementation to a slow one by just changing the interface object. Hopefully, CLOS inlining can do the rest from there.

guicho271828 commented 8 years ago

What I want is a parametric types with a good design. And more data-structure implementations. With a consistent, reliable interface.

I noticed that my wording was not appropriate, I meant LIL is doing very good job regarding its design and consistency and reliable interface so it is itself valuable even without transformation.

it won't be as fast as dedicated defstructs in each case. It is on the other hand much more flexible.

In the paper, it is said that the design separates the dispatch on algorithm and the dispatch on data. I interpreted it as that the arguments can be structures or arrays so the element access can be fast enough. If everything is implemented as such, then the only bottleneck would be on the dispatch on algorithm (interface class).

fare commented 8 years ago

Yes, and yes. And the CLOS inlining should be perfect to dispatch on the interface alone.

guicho271828 commented 8 years ago

Track https://github.com/guicho271828/lisp-interface-library/tree/usability for progress.