@weekend_editor @CuratedHackerNews @DylanLang

From what I can tell based on the name and the image (there's no doc?) what this is doing is looking at each symbol in the current environment and deciding how to highlight it based on its "kind".

Is it a function? Make it blue. Is it a special form? Make it purple. etc.

(But a brief look at the elisp code reveals long lists of hard-coded symbol names, so I dunno.)

Whereas Dylan's optimization coloring is, as you say, showing how method dispatch is optimized or not.

Compiler inlined the code of the exact method? Make it dark grey. Method will be selected at run time? Make it red. etc.

So very different beasts but the name Semantic Coloring definitely has the same ring to it.

https://opendylan.org/getting-started-ide/coloring.html

#DylanLang

@hajovonta @simon_brooke

(reduce #'eq '(x x x)) -> NIL

You really have to do something like

(reduce (lambda (a b) (and (eq a b) a)) args)

which fails for `(nil nil nil), or better

(every (lambda (a) (eq a (car args))) (rest args))

Both are a little annoying. I prefer n-ary functions.

That said, #DylanLang makes all of the comparison functions binary and I don't remember ever needing an n-ary version. But if there's no performance penalty I say go for it.

@thezerobit

I work on LSP for #DylanLang sometimes. If I ever give up on Dylan maybe I'll work on similar things for CL and try to make them usable.

Current status: fixing the #DylanLang sockets library to have better error messages. Considering whether I should dive one level deeper and finish this rewrite of the sockets code I found to match the POSIX APIs and support IPv6: https://github.com/dylan-foundry/posix-sockets

#yhoti