11 ms·
Chez Scheme as the Racket VM
- peatmoss 10y agoThe benchmarks for Chez Scheme are pretty impressive. Provided Racket-on-Chez is able to captitalize on that, this is pretty exciting. Also, that makes it hypothetically possible that HN could end up running on Chez's VM because HN is written in Arc, which is I believe written in Racket, which may in the next year be written for Chez Scheme's VM.
- codemac 10y agoI think it may be faster to just port, though are there larger libraries that Arc depends on in Racket that you'd also have to significantly port?
- peatmoss 10y agoI honestly have no idea. I think I remember reading that Arc may also be pinned to a somewhat old version of Racket / PLT Scheme. I could be misremembering though. Depending on how portable Arc is to new versions of Racket, I'd guess they could move to a new Chez-backeneded Racket without any need to port.
- hjek 10y agoArc works fine on newer versions of Racket using the MzScheme legacy language bindings.
- deleted 10y ago[deleted]
- JoelMcCracken 10y agoThe last time I checked, arc required a pretty old version of racket that supported mutable cons cells. Not sure if that's still true, but AFAIK all work on arc has been stalled for quite a while.
- soegaard 10y agoFWIW Racket has two types of cons cells: mutable and immutable. And if you know what you are doing - then you can abuse the FFI to mutate the immutable ones (but don't tell anyone) using unsafe-set-mcar! and unsafe-set-mcdr!.
- acchan 10y agoThere's a community version of the language being developed here: https://github.com/arclanguage/anarki https://github.com/arclanguage/anarki It works with the latest Racket versions and includes a HN clone. You can see it running here: http://arclanguage.org/forum http://arclanguage.org/forum It's true that pg isn't working on it though. I wonder if he's ever getting back to it.
- JoelMcCracken 10y agoI'm not sure if its super important that PG gets back to it. To be honest, I'd love if someone made a summary of what, in 2017, makes arc unique and worth looking into.
- na85 10y agoIs Chez "scheme all the way down"?
- aidenn0 10y agoThe only "scheme all the way down" implementation I know of is T. It's just too much of a pain to fully self-host the garbage collection code, and it's not exactly clear what the gain of doing so is.
- pjmlp 10y agoThe satisfaction of not depending on anything else other than some Assembly. The moment another language gets used, like C, there is this misunderstanding among compiler design illiterates that without the use of that programming language, writing the compiler wouldn't be possible at all.
- nickpsecurity 10y agoPreScheme: https://en.m.wikipedia.org/wiki/PreScheme https://en.m.wikipedia.org/wiki/PreScheme Only C in one of the implementations was an I/O shim for the C-based OS. That could be removed for purity but they were about pragmatism.
- deleted 10y ago[deleted]
- nickpsecurity 10y agoWell, that deleted comment was one of most respectable I've seen in a while. You were accurate about its features but maybe missed the justification: it was a replacement for C in terms of low-level use and performance (ideally). That made typical Scheme features impossible. Additionally, it was a critical part of VLISP project to mathematically verify a Scheme (Scheme48). They had to balance power and complexity carefully. So, it was efficient, gave you some Scheme power, and mathematically verified for correctness at the algorithm level for VLISP version. So, not as nice as a full Scheme but great in other ways and used to write a Scheme.
- Johnny_Brahms 10y agoIf anyone is looking for benchmarks, the most comprehensive comparison of scheme implementations can be found here: http://ecraven.github.io/r7rs-benchmarks/benchmark.html http://ecraven.github.io/r7rs-benchmarks/benchmark.html
- reitzensteinm 10y agoWow, Chez mostly beats out Stalin.
- Johnny_Brahms 10y agoIf we look at the benchmarks where one can expect stalin to be fast (numeric, and more specifically floating point benchmarks.) stalin is really in it's own league. The puzzle benchmark is nice, since it benchmarks many common compiler optimizations - with code written to be easily optimized. Stalin of course wins. The other benchmarks are written in a more general style, which I have found does not always produce the best output with stalin. If I would spend some time optimizing these benchmarks, I could probably make Stalin come out on top a lot more often. That, however, takes you are back to the old problem: A heavily optimized C program looks like C. A heavily optimized [insert functional programming language here. Most often haskell] program looks like shit. What impresses me the most about chez is that it takes idiomatic scheme code, and produces neat and fast machine code.
- lomnakkus 10y ago> A heavily optimized C program looks like C. Really? I haven't found that to be the case very often. > A heavily optimized [insert functional programming language here. Most often haskell] program looks like shit. Here we definitely agree :). It's also worth mentioning that it's not often worth it to optimize very much of your code. (The 80-20, or perhaps 95-5, rule applies in full force.) Obviously, it's still worth it to have compilers optimize idiomatic code.
- pjmlp 10y ago> A heavily optimized C program looks like C. Not in the 80's and early 90's. What C has, is 40 years of development effort invested by several multinationals with deep pockets and researchers, improving the optimizer algorithms of their compilers.
- throwaway7645 10y agoI'm curious why people don't prefer Chez Scheme to Racket if it is so fast and can make real binaries (I think anyway). Maybe because until recent it was proprietary. Racket is cool, but I already have Python which is similar from a performance perspective. Chez with the Racket ecosystem might be worth a switch.
- catnaroek 10y agoRaw performance isn't all there is to a programming language. Racket is so much more flexible and beautifully designed than Python.
- throwaway7645 10y agoAgreed, but if Python is your main weapon of choice, one will usually want to invest next in something really fast to bridge the gap. I wasn't aware Racket is that much faster....I'd like to see some benchmarks.
- catnaroek 10y agoI tend to think of Racket as an alternative to Python, rather than a complement to it. C and Rust fit better the latter description. Racket is faster than CPython, but that isn't anywhere near the top of my list of reasons to use Racket instead of Python. When speed is a priority, Rust and MLton (Standard ML) are both much faster than Racket. But: (0) Racket is much more malleable than either Rust or SML. Rather than bash your head trying to model your problem domain in the existing language, you can redefine the language until it's the ideal tool for your problem domain. (1) Unlike other languages that also advertise malleability (Common Lisp, Smalltalk, etc.), Racket is malleable in principled ways, so you can define abstractions without figuratively stomping on abstractions defined by other people (which you might also be interested in using).
- throwaway7645 10y agoHow often are you doing something that needs to be turned into a DSL, or is this something that you do all the time once you grok it?
- eggy 10y agoI'm glad I've stuck with Racket. The work on it continues to surprise me in many ways. I have Chez and Racket on my box, and Wasp Lisp. Now I can look forward to a fast Racket with scheme code I can dig into vs. C, which I am only ok at.
- abhi18av 10y agoThe very same delight, over here as well :)
- abhi18av 10y agoThis is like a secret wish come true!