libera/#commonlisp - IRC Chatlog
Search
17:35:32
random-nick
ecraven: slime should be able to look at the inferior lisp's *features* and show the code as not commented out
17:38:55
lotuseater
random-nick: I tried, first not having :lispm in it, then it looks like a comment, then (pushnew :lispm *features*) and it shows it like code
20:40:38
phoe
also, in the example at https://coalton-lang.github.io/20211010-introducing-coalton/ where you (define (hello name) ...) you have "these lines are Common Lisp" - what is the variable UNIT, where does it come from?
20:43:37
stylewarning
This may only increase confusion but https://github.com/coalton-lang/coalton/blob/main/src/library/types.lisp#L6
20:44:58
phoe
looks to me like COALTON:UNIT is a self-evaluating symbol, and you also described that (deftype unit () '(eql unit))
20:50:54
lotuseater
with coalton a bit of Haskell feeling comes up :) but it's more inspired by SML iirc
20:56:55
stylewarning
phoe: from Coalton’s perspective, Unit is a type with one value, Unit. There’s no concept of a symbol in Coalton. In Lisp, though, Unit is implemented as a symbol, so indeed it just looks like a self-evaluating symbol. (Very pedantic of course.)
20:57:33
stylewarning
It’s logically equivalent to the pure Coalton code: (define-type Unit Unit) — but isn’t that way because it needed to be “bootstrapped”
21:07:21
fitzsim
I had been pulling from the old repo from time to time and thought development had stopped
21:09:26
phoe
stylewarning: in define-type binary-tree, is (Leaf) supposed not to have any value in it?
21:11:34
phoe
Coalton is case-insensitive by default since it uses the standard Lisp readtable - is that correct?
21:20:11
phoe
also, beach is gonna scold you about the use of term "CLOS classes" once he wakes up; you may want to change that to "standard classes" :D
21:21:32
moon-child
phoe: do you suppose he will acknowledge something that has not a formal specification?
21:29:16
hayley
stylewarning: Dumb question, are you aware of the work on the Strongtalk type system?
21:29:58
hayley
I see Coalton went down an ML-esque route, but they could type Smalltalk while preserving the dynamicism of it.
21:30:40
stylewarning
I wonder what it’s type language looks like and what invariants it can express
21:32:57
hayley
https://upload.wikimedia.org/wikipedia/commons/thumb/3/3c/Strongtalk-system.png/781px-Strongtalk-system.png Looks to have parametric polymorphism at least.
21:33:00
jcowan
I worked on a project called Steme which was like Coalton but for Scheme. Unfortunately it broke down on irreconcilable design differences. (We didn't learn about Coalton until near the end.) I think my insistence that Steme should be pure was probably a mistake, but the idea of interoperating co-languages was there.
21:34:15
moon-child
raku's runtime is intended to permit interoperation of disparate languages. Currently it only hosts raku and its bootstrapping subset, but there's no reason others couldn't be added
21:34:57
fitzsim
"See the eval example above.": the list-length example of match shows the use of the wildcard, where the eval example doesn't
21:35:32
stylewarning
I think I just meant as an example of MATCH but maybe the language could be clearer
21:37:02
jcowan
no need for explicit bridges, though; you could write the type of a Scheme function in a Steme declaration, provided you certified its purity, and Scheme could call Steme directly.
21:40:59
stylewarning
(At no cost but a few extra characters typed and microseconds spent compiling)
21:42:25
jcowan
If your Coalton function calls a lot of Lisp code or vice versa, it's harder to read with explicit bridging. The Steme idea was to define a bridge just once, not every time it is used.
0:19:10
aeth
stylewarning: oh, you did that? Shouldn't you be typeerror instead of stylewarning, then?
4:00:44
Devon
https://directory.FSF.org lists Emacs CL, Gnu CL and SBCL listed but not ABCL, CCL, Clasp, CLISP nor ECL. Perhaps these unlisted maintainers would like to provide a blurb for the directory.