3 ms·
If you feel like sharing the ideas, I’m sure many people would be interested in seeing potential example applications where this (abstract and somewhat uncommon
by ssivark 6y ago
If you feel like sharing the ideas, I’m sure many people would be interested in seeing potential example applications where this (abstract and somewhat uncommon, in other languages) capability can be put to good use.
- srcreigh 6y agoYou can go as complex as your own type system. One type system was added to Racket called Typed Racket. No new features were needed in the language or tooling, they just used Racket macros to build a Racket with static compiler errors which integrates with the IDE. Two similar cases. One is Typescript. That's a new language with different syntax, a new compiler which targets JS. It also provides its own tooling for IDEs. Another is Python. Over time there were PEPs to add syntax for type hints, and now type systems are being added to the language. When Racket did this, they were able to do it in Racket without adding more features to the compiler or IDE. There's built in support for static analysis, compiler errors, editor integration. Not to mention a way to organize all the information you need to do type checking in the compile steps, and make that information accessible in the right places. The new type safe Racket was built using plain ol Racket. There's a reasonably accessible paper about this here: https://www2.ccs.neu.edu/racket/pubs/scheme2007-ctf.pdf https://www2.ccs.neu.edu/racket/pubs/scheme2007-ctf.pdf So here are some of my ideas: 1. Play around with static analysis checks. I want to rebuild Typescript style structural inference to Racket. 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. I love the focus on great error messages. Maybe one day I will contribute to Typed Racket :) Making your own compiler error appear in Racket is just 5 lines of code. https://gist.github.com/srcreigh/a0a087adc26e15af0160e8866d48cd1c https://gist.github.com/srcreigh/a0a087adc26e15af0160e8866d4... 2. New syntax for creating structs. Racket had structs that are initialized like (point 1 2). What if you want keyword syntax ie (point #:x 1 #:y 2)? What if you want that to work with match too? Do you want a JS-style syntax such as (point #:x #:y 2) which pulls in x as an identifier? You can do all this! The rebellion library is pretty awesome in this regard [1], with some sample usage of it in a script here [2]. [1]: https://docs.racket-lang.org/rebellion/Data_Types.html https://docs.racket-lang.org/rebellion/Data_Types.html [2]: https://github.com/srcreigh/shift-remapper/blob/main/generate.rkt https://github.com/srcreigh/shift-remapper/blob/main/generat...
- sorawee 6y ago> 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 https://github.com/racket/typed-racket/pull/952 for RFC and https://github.com/racket/typed-racket/pull/948 https://github.com/racket/typed-racket/pull/948 for the implementation.
- srcreigh 6y agoExcellent. Can't wait to try it out. It's exciting to think of "Deep" checking as a complement to optional checking. Use a mix of both in one code base to play their strengths. For example it'd be great to define a deep type checked module for parsing data. You get static errors and runtime validation too. But, also, use that module from an optionally type checked module, which doesn't add any extra runtime costs if some of your other code / dependencies are untyped.