Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crunch – a Scheme compiler with a minimal runtime

more-magic.net

Post reply on HN
Print view View original

41–50 of 73 posts

Re: Crunch – a Scheme compiler with a minimal runtime

#41

Post by nesarkvechnep »

diggan wrote: post #27
fouric wrote: post #8

For Common Lispers such as myself, who are vaguely aware of developments in the Scheme space: the most important difference between CRUNCH and Chicken appears to be that, while both compile down to C/object code, CRUNCH is additionally targeting a statically-typed subset of Scheme. Opinion: this is great. The aversion of Lispers to static types is historical rather than intrinsic and reflects the relative difference…

> Now that types and tools are advancing, static Lisps are feasible, and I love that. Haven't that been feasible for a pretty long time already? Judging by how well-received (or not) they've been, it seems there isn't much demand for it. Things like clojure.spec and alike (compile-time + run-time typing) seems much more popular, but isn't static.

There isn’t much demand for Lisps in general.

Re: Crunch – a Scheme compiler with a minimal runtime

#42

Post by davexunit »

jxy wrote: post #14

> No support for first class continuations I'm not sure about how people would feel about this. I have mixed feelings. It feels like a loss of many things. What are the gains from ditching continuations?

It's fine because this is a static subset of Scheme that you could use to, say, implement a runtime for a full Scheme. As a Scheme programmer, it feels nice to be able to implement your Scheme in something very close to Scheme instead of having to use C.

Re: Crunch – a Scheme compiler with a minimal runtime

#44

Post by outworlder »

JonChesterfield wrote: post #34

> Other targets are possible, like GPUs. I don't know anything about that, so if you are interested and think you can contribute, please don't hesitate to contact me. The freestanding macro suggests most of the heavy lifting is done. Stuff the GPU targets will struggle with in no particular order: - setjmp / longjmp - signals (if used?) - threads - fast alloc/free - stack will be smaller than chicken expects I don't…

> - setjmp / longjmp

Isn't that mostly needed by call/cc, which is not supported by Crunch?

Re: Crunch – a Scheme compiler with a minimal runtime

#45

Post by neonscribe »

jxy wrote: post #14

> No support for first class continuations I'm not sure about how people would feel about this. I have mixed feelings. It feels like a loss of many things. What are the gains from ditching continuations?

First-class continuations remains the hardest nut to crack to implement any full specification of Scheme, especially if performance and/or compactness and/or simplicity of implementation and/or integration with other languages (C, C++, Java, etc.) is a priority. Scheme--, a subset with only downward continuations, i.e. continuations that could be implemented using only C setjmp and longjmp or equivalent, would still be an extremely useful language, but it is much harder to gather a community for such a project.

Re: Crunch – a Scheme compiler with a minimal runtime

#46

Post by norir »

packetlost wrote: post #32
jnxx wrote: post #30

Earlier quoted context omitted.

What are the main differences between OcamML and a statically typed Lisp?

Type inference is probably the biggest thing. You would need explicit "phases" to expand macros, disallow macro expansion at runtime, and implement bi-directional type inference HM-style to get even close to what OCaml has. To be honest, I'd kill for a Lisp that had the same type system as OCaml, but I suspect the closes we'll get is basically Rust (whose macro system is quite good).

There is a simpler solution than type inference to removing type annotations while retaining types: remove the distinction between variable and type names. The way that you handle multiple instances of a type is to define an alias for the type. In pseudocode it might look like:

  type Divisor Number
  def divide(Number, Divisor) = Number / Divisor
As compared to:

  def divide(number: Number, divisor: Number) = number / Divisor
I have implemented a compiler for a language that does this with different (less familiar) syntax. It's a bit more complicated than described above to handle local variables but it works very well for me.

Re: Crunch – a Scheme compiler with a minimal runtime

#47

Post by reikonomusha »

packetlost wrote: post #40
shawn_w wrote: post #36

Earlier quoted context omitted.

Racket has Typed Racket, which while not Hindley-Miller can do some type inference. There's also the plait language which says its type system is similar to ML: https://docs.racket-lang.org/plait/index.html And Hackett, inspired by Haskell: https://lexi-lambda.github.io/hackett/ And Common Lisp has coalton: https://coalton-lang.github.io/

Most of those aren't really ready for production use except maybe Typed Racket, which I consider to be too "weak" and took a route with annotations that I'm not a fan of. Coalton is very interesting, I've been following it for a bit. Carp [0] is another one that I've been following. [0]: https://github.com/carp-lang/Carp

Coalton is used in production for quantum computing systems and soft real-time control system automation. There are also (a small number of) Coalton jobs.

Re: Crunch – a Scheme compiler with a minimal runtime

#48

Post by int_19h »

cardanome wrote: post #7
nudpiedo wrote: post #2

so if I understand this right, it could be a way to run scheme on esp32 and similar microcontrollers, isn't it? Also its small size would make it a perfect target to compile to typescript/deno/wasm without rejecting the s-exp power and runtime possibilities in its full chicken code at the backend...

Not a scheme, but for running a lisp on microcontrollers uLisp is pretty amazing. http://www.ulisp.com/ You even get a REPL and everything WHILE running on the hardware. Super easy to set up and get going. Though as it is interpreted so you will of course not have native performance. Still very useful for prototyping and hobbyist projects.

OTOH if you want something that gives you a REPL and everything directly on the hardware but is also not as slow as your typical interpreter, look at Forth.

Re: Crunch – a Scheme compiler with a minimal runtime

#49

Post by JonChesterfield »

outworlder wrote: post #44
JonChesterfield wrote: post #34

> Other targets are possible, like GPUs. I don't know anything about that, so if you are interested and think you can contribute, please don't hesitate to contact me. The freestanding macro suggests most of the heavy lifting is done. Stuff the GPU targets will struggle with in no particular order: - setjmp / longjmp - signals (if used?) - threads - fast alloc/free - stack will be smaller than chicken expects I don't…

> - setjmp / longjmp Isn't that mostly needed by call/cc, which is not supported by Crunch?

I thought chicken used it to treat the C stack as an arena for the GC, with longjmp acting as part of garbage collection. I don't see how it would help for call/cc, that needs a reified stack to handle repeat invocations.

Re: Crunch – a Scheme compiler with a minimal runtime

#50

Post by packetlost »

reikonomusha wrote: post #47
packetlost wrote: post #40

Earlier quoted context omitted.

Most of those aren't really ready for production use except maybe Typed Racket, which I consider to be too "weak" and took a route with annotations that I'm not a fan of. Coalton is very interesting, I've been following it for a bit. Carp [0] is another one that I've been following. [0]: https://github.com/carp-lang/Carp

Coalton is used in production for quantum computing systems and soft real-time control system automation. There are also (a small number of) Coalton jobs.

Quantum computing control systems is exactly the domain I've spent about half a decade doing, it's really not the production-like environment you think it is. Speed of iteration and flexibility to allow for changes to hardware is tantamount to success. It's also a lot easier to accept risk to breakages in the language when the author works at your company too.
Post reply on HN