3 ms·

I believe the next evolution will be to combine Rust and Lisp; a programming language as flexible as LISP without giving up the safety of Rust, including a type

by zaarn 7y ago

I believe the next evolution will be to combine Rust and Lisp; a programming language as flexible as LISP without giving up the safety of Rust, including a typesystem that can be entirely coded in the language itself, safely.

bluejekyll 7y ago
Rust’s macro system gives you this already. Is there something you see it not providing that the language you’re imagining would?
- zaarn 7y ago
  Rust's current macro's aren't as powerful as I would like them, and procedural macros are far more difficult and extremely hard to properly develop and debug. The substitution macros aren't that much fun either since they lack certain capabilities (like introducing a new variable into the current scope without having to specify the name redundantly). Without a lot of external libraries, procedural macros are almost impossible to write in my experience. Neither of them allows one to properly code onto the type system or replace it and neither is properly supported by the IDEs (or RLS).
  - cztomsik 7y ago
    rust proc macros are limited because they need to be in a separate crate and syn is also not that much easier to work with, it's too level IMHO
- mrkeen 7y ago
  I'd like to be able to hide Future, Vec, Result, etc. behind a trait.
mrkeen 7y ago
> a typesystem that can be entirely coded in the language itself The closest thing to this I can think of is Racket. It's supposedly powerful enough to embed Haskell in it https://lexi-lambda.github.io/hackett/ https://lexi-lambda.github.io/hackett/
- zaarn 7y ago
  I would imagine something closer to rust in terms of base and then being able to put Haskell on top without loosing any safety guarantees. Or possibly even allowing an arbitrary type system as long as you can prove it's sound with the guarantees of the language.
  - FrankHB 7y ago
    Types are closed terms of contracts encoded in a language within specific phases. If you really need any guarantees without further knowledge shaped before running, then, besides the typechecking, the typing rules should also be programmable by users (rather than the language designer) for the sake of providing proofs. The base system must practically have no mandated static type systems at all, which is far from Rust.
    - zaarn 7y ago
      I would disagree, you need a solid typesystem and then any other typesystem must prove to be a compatible superset.
- FrankHB 7y ago
  It's about the ability, not the reality. As Racket, the base language can have no explicit rules for any type systems to be embedded. There can be more powerful candidates, e.g. Kernel: https://web.cs.wpi.edu/~jshutt/kernel.html https://web.cs.wpi.edu/~jshutt/kernel.html. Racket is special because its designers provide dedicated support of language-oriented programming. But that is about ecosystems, not typesystems.
krcz 7y ago
I have something similar in mind: I want to have homoiconicity but with typed data underneath (instead of just untyped lists) in order to add some structure and let compiler help you with macros. That plus advanced type system with gradual verification. I'm in early exploration phase, but I have some ideas written down: https://github.com/krcz/zygote https://github.com/krcz/zygote .

by zaarn 7y ago

bluejekyll 7y ago

Rust’s macro system gives you this already. Is there something you see it not providing that the language you’re imagining would?

zaarn 7y ago
Rust's current macro's aren't as powerful as I would like them, and procedural macros are far more difficult and extremely hard to properly develop and debug. The substitution macros aren't that much fun either since they lack certain capabilities (like introducing a new variable into the current scope without having to specify the name redundantly). Without a lot of external libraries, procedural macros are almost impossible to write in my experience. Neither of them allows one to properly code onto the type system or replace it and neither is properly supported by the IDEs (or RLS).
- cztomsik 7y ago
  rust proc macros are limited because they need to be in a separate crate and syn is also not that much easier to work with, it's too level IMHO
mrkeen 7y ago
I'd like to be able to hide Future, Vec, Result, etc. behind a trait.

mrkeen 7y ago

> a typesystem that can be entirely coded in the language itself The closest thing to this I can think of is Racket. It's supposedly powerful enough to embed Haskell in it https://lexi-lambda.github.io/hackett/ https://lexi-lambda.github.io/hackett/

zaarn 7y ago
I would imagine something closer to rust in terms of base and then being able to put Haskell on top without loosing any safety guarantees. Or possibly even allowing an arbitrary type system as long as you can prove it's sound with the guarantees of the language.
- FrankHB 7y ago
  Types are closed terms of contracts encoded in a language within specific phases. If you really need any guarantees without further knowledge shaped before running, then, besides the typechecking, the typing rules should also be programmable by users (rather than the language designer) for the sake of providing proofs. The base system must practically have no mandated static type systems at all, which is far from Rust.
  - zaarn 7y ago
    I would disagree, you need a solid typesystem and then any other typesystem must prove to be a compatible superset.
FrankHB 7y ago
It's about the ability, not the reality. As Racket, the base language can have no explicit rules for any type systems to be embedded. There can be more powerful candidates, e.g. Kernel: https://web.cs.wpi.edu/~jshutt/kernel.html https://web.cs.wpi.edu/~jshutt/kernel.html. Racket is special because its designers provide dedicated support of language-oriented programming. But that is about ecosystems, not typesystems.

krcz 7y ago

I have something similar in mind: I want to have homoiconicity but with typed data underneath (instead of just untyped lists) in order to add some structure and let compiler help you with macros. That plus advanced type system with gradual verification. I'm in early exploration phase, but I have some ideas written down: https://github.com/krcz/zygote https://github.com/krcz/zygote .