cosmos72 / cl-parametric-types Goto Github PK

1. So this is implemented in pure common lisp without using any c/c++ code and cffi?

2. Any plans for future updates and getting out of beta?

I am open to suggestions :)

Given a general case like

(template (<t1> <t2>)
  (defstruct foo
    (bar nil :type <t1>)
    (baz nil :type <t2>)))

my idea for partial specialization syntax is something like:

(template (<t>)
  ;; applies if and only if <t1> and <t2> defined above
  ;; are BOTH equal to (array <t>) for some <t>
  (:specialized-for ((array <t>) (array <t>))
  (defstruct foo
    (bar nil :type (array <t>))
    (baz nil :type (array <t>))))

I also had a look at OPTIMA, but if I introduce general pattern matching, once there are multiple partial specializations for the same general template, I have no idea how to write the algorithm for deciding which one is the most specific (or to decide that none is more specific than the others)

Any thoughts? @guicho271828 ?

there are several past attempts on implementing parametric types on common lisp.
as far as remember, cl-adt, https://github.com/danlentz/dstm-collections/blob/master/attic/adt.lisp . Mine is https://github.com/guicho271828/trivialib.typevar (but I'd say this is a failed attempt because it is based on CLOS/structure mixture and it was hard to debug).

This is a very interesting project, and I'd like to hear more about the design philosophy of this library, among which what I'd like to know is whether this library is designed for speed (after compilation). Well, every CLer would know how ugly C++ template is, so essentially no need to complain about its ugliness in the readme :)

https://github.com/tarballs-are-good/cl-algebraic-data-type

The cl-adt library compiles down to structs, we should be able to write a TEMPLATE form for defdata.

This is half a feature request, half a "I'll do it sometime".

What do you think about this idea? Just off the top of your head I mean :-)

https://github.com/show-matz/CL-STL is an attempt to implement STL in CL. It's based on CLOS (so it is slow) but yesterday the author, @show-matz , gave a talk on it at Shibuya.lisp Lisp Meetup and I had an opportunity to discuss this project.

• CLOS is slow but its overhead can be compiled away by inlined-generic-function. I asked him to compare the performance of CL-STL with vs without inlining.
• CL-STL is a 5-year old personal project and most containers are already implemented (e.g. deque, linked-list (bidirectional), map/set/multimap/multisets)
• It does not have templates though.
• It is aimed at reprecating C++, rather than integrating it into common lisp. According to him, his initial motivation of writing the library is to learn lisp. So when we use his code we have to refactor it.