7 ms·

I can testify to a lot of the difficulties Robert Strandh talks about here. We implemented a Common Lisp in C++ that interoperates with C++ (https://github.com

I can testify to a lot of the difficulties Robert Strandh talks about here. We implemented a Common Lisp in C++ that interoperates with C++ (https://github.com/clasp-developers/clasp.git https://github.com/clasp-developers/clasp.git). I ended up implementing a lot more C++ code than I wanted to and then replacing much of it with Common Lisp versions (during startup) because it's easier to maintain and we can use type inference to improve the performance of Common Lisp code while C++ code is 'stuck' with the types you compile it with. Bootstrapping is hard.

betterunix2 6y ago
"we can use type inference" Technically you cannot use type inference in Common Lisp, only in a subset of the language. This is not hard to prove: you can embed a language for which general type inference is impossible (i.e. for which some expressions must have explicit type annotations), like System F, in Common Lisp. One of my complaints about Common Lisp is that the type system is really annoying when you have complex types.
- aidenn0 6y ago
  Type inference isn't all-or-nothing. If you can infer even one type in one block of code, you can generate more efficient code.
- reikonomusha 6y ago
  > One of my complaints... Then build a language and type system atop, like with Coalton [0]. Lisp is for language building. Even Hindley-Milner was first implemented atop Lisp in 1973 [1]. [0] https://github.com/stylewarning/coalton https://github.com/stylewarning/coalton [1] http://www-public.imtbs-tsp.eu/~gibson/Teaching/CSC4504/ReadingMaterial/GordonMMNW78.pdf http://www-public.imtbs-tsp.eu/~gibson/Teaching/CSC4504/Read...
dleslie 6y ago
I like what you're doing, but I really wish you'd provide debs and rpms for x86 and arm; I use common lisp on machines with very little ram, and compiling is too much of a hassle. FWIW, ecl and sbcl are my go-tos.
- fiddlerwoaroof 6y ago
  I second this: making it easy for users to use your language implementation is very valuable. I routinely test my Lisp on every implementation I can reliably get my hands on, and I’ve never been able to build a good binary for clasp.
  - stevelosh 6y ago
    Thirded. I would also add Clasp to my projects' list of implementations to run unit tests on[1] if I could easily install it on Ubuntu with a .deb. [1]: e.g. adding a test-clasp clause to https://github.com/sjl/cl-digraph/blob/master/Makefile#L14-L32 https://github.com/sjl/cl-digraph/blob/master/Makefile#L14-L...
    - phoe-krk 6y ago
      > if I could easily install it on Ubuntu with a .deb. Or even via Roswell - if that is even remotely possible.
      - dleslie 6y ago
        Clasp is supplied via Roswell but fails to compile on Arm64.
      - stevelosh 6y ago
        I don't use/like Roswell, so I'd really prefer a .deb if at all possible.
- drmeister 6y ago
  Thank you. So debs for debian? I have great collaborators working with me now that could do this. We have one for Arch I believe. I just haven't prioritized this yet.
  - dleslie 6y ago
    Debian and its derivatives, yes; I do most of my lisp from raspbian these days, but it's Debian compatible.

betterunix2 6y ago

"we can use type inference" Technically you cannot use type inference in Common Lisp, only in a subset of the language. This is not hard to prove: you can embed a language for which general type inference is impossible (i.e. for which some expressions must have explicit type annotations), like System F, in Common Lisp. One of my complaints about Common Lisp is that the type system is really annoying when you have complex types.

aidenn0 6y ago
Type inference isn't all-or-nothing. If you can infer even one type in one block of code, you can generate more efficient code.
reikonomusha 6y ago
> One of my complaints... Then build a language and type system atop, like with Coalton [0]. Lisp is for language building. Even Hindley-Milner was first implemented atop Lisp in 1973 [1]. [0] https://github.com/stylewarning/coalton https://github.com/stylewarning/coalton [1] http://www-public.imtbs-tsp.eu/~gibson/Teaching/CSC4504/ReadingMaterial/GordonMMNW78.pdf http://www-public.imtbs-tsp.eu/~gibson/Teaching/CSC4504/Read...

dleslie 6y ago

I like what you're doing, but I really wish you'd provide debs and rpms for x86 and arm; I use common lisp on machines with very little ram, and compiling is too much of a hassle. FWIW, ecl and sbcl are my go-tos.

fiddlerwoaroof 6y ago
I second this: making it easy for users to use your language implementation is very valuable. I routinely test my Lisp on every implementation I can reliably get my hands on, and I’ve never been able to build a good binary for clasp.
- stevelosh 6y ago
  Thirded. I would also add Clasp to my projects' list of implementations to run unit tests on[1] if I could easily install it on Ubuntu with a .deb. [1]: e.g. adding a test-clasp clause to https://github.com/sjl/cl-digraph/blob/master/Makefile#L14-L32 https://github.com/sjl/cl-digraph/blob/master/Makefile#L14-L...
  - phoe-krk 6y ago
    > if I could easily install it on Ubuntu with a .deb. Or even via Roswell - if that is even remotely possible.
    - dleslie 6y ago
      Clasp is supplied via Roswell but fails to compile on Arm64.
    - stevelosh 6y ago
      I don't use/like Roswell, so I'd really prefer a .deb if at all possible.
drmeister 6y ago
Thank you. So debs for debian? I have great collaborators working with me now that could do this. We have one for Arch I believe. I just haven't prioritized this yet.
- dleslie 6y ago
  Debian and its derivatives, yes; I do most of my lisp from raspbian these days, but it's Debian compatible.