typed-racket VS gui

Turns out, Shallow was slower than it needed to be for types of built-in math (+, *, ...). PR here: https://github.com/racket/typed-racket/pull/1316

Last weekend, I put together a working sample for how to show multiple syntax errors from Racket macros. It works in DrRacket and racket-xp-mode. It's based on Typed Racket.

https://gist.github.com/srcreigh/f341b2adaa0fe37c241fdf15f37...

The well-documented Racket `raise-syntax-error` will let you display 1 syntax error at a time. It works by throwing an exception during macro expansion hence you only get 1 error in your IDE. That code lets you highlight 2+ errors.

Please build a type system in Racket! I would love to try it out.

Helpfully, the above sample code is an example of how to store compiler-level state. So next, just wrap all your base forms, add some type declaration syntax, type inference, etc.

I would love to have a language that can be used to define a customized type system in Racket.

Typed Racket is an incredible feat. Can you imagine adding an entire type system without writing a separate compiler? Using all the batteries included with your language?

However I don't like that Typed Racket enforces soundness with Runtime checks, I much prefer TypeScript style checking. I also have run into some pretty confusing messages ie [1]. Diversity is healthy, it'd be nice to have static typechecking systems to choose from for Racket.

[1] https://github.com/racket/typed-racket/issues/1021

> I like how TS is unsound (has no runtime performance penalty for mixing untyped code), and is easily disabled via any if it's in the way.

This is already done. See https://github.com/racket/typed-racket/pull/952 for RFC and https://github.com/racket/typed-racket/pull/948 for the implementation.

> The problem with learning Lisp is `(a ,b c)

If you can understand "String ${interpolation}", you can understand list quasiquoting.

> But the problem remains: it only takes one wizard to make reading code impossible by outsiders.

This really is a Lisp meme. There are plenty of Lisp wizards like Guy Steele, Rich Hickey, and Matthew Flatt. The wizards perform the magical act of making code legible and intelligible. I have stumbled around several Clojure and Racket code bases and never felt like "I should understand this code but the features of Lisp make it impossible to know for sure." "Infinite power" macros and whatever are really only used sparingly and generally when it's impossible to achieve a goal otherwise. No one is doing (define + -).

> But this means no-one outside of the language/system developers know the language, this means Lisp tends to be write-only by design - not in the line-noise meaning, but in the obscure foreign language meaning.

I, as a Racket novice, have been able to add candlesticks [1] to the plot library without learning much about it. I have also debugged DrRacket (an IDE) to uncover that Racket GUI operations performed significantly worse if non-integer scaling was used [2]. At no point when I was going through Racket internal code did I ever feel it was write-only. In fact, it was quite convenient to modify Racket internal source code, rebuild, and test changes in a way that would be much more difficult in Java or C++.

> You certainly can not do that, but if you choose to not do that, why pick Lisp?

Built in rationals.

The ergonomics of defining [XML / JSON / etc] data as S-expressions and doing things like pattern matching on that data.

Great, coherent integration between GUIs, plots, statistics functions, and all the other bits of Racket's batteries inclusions.

You still have access to all the other great features that other languages have borrowed from Lisp like REPL development, package managers, good IDE tools, etc.

It is nice to learn the meta-syntax of parentheses once and know that the code will always look like that. No need to consider if some feature is implemented as a syntactically different new keyword, annotation, function call, or whatever. It'll always be a (feature).

> something you have to conciously work for with Lisp.

Plenty of languages have style guides, linters, static analysis tools, etc. to make sure the code conforms to certain restrictions. Lisp feels no different in this regard.

[1] https://docs.racket-lang.org/plot/renderer2d.html#%28def._%2...

[2] https://github.com/racket/gui/commit/20e589c091998b0121505e2...

Please file a bug report at https://github.com/racket/gui/issues

https://github.com/racket/gui/issues/207#issuecomment-753406612