5 ms·
#lang is much more than shebangs. Racket #langs are implemented on top of Racket - they can be nothing more than alternative syntaxes, or they can have differen
by dTal 5y ago
#lang is much more than shebangs. Racket #langs are implemented on top of Racket - they can be nothing more than alternative syntaxes, or they can have different semantics (written in Racket). This has the effect of rendering different Racket #langs interoperable within a project. This is wildly powerful - someone reimplemented Python entirely as a #lang, for instance, which meant that Racket could use (pure) Python libraries directly, and vice versa.
It's an entirely different philosophy, which aims to allow to use "the best tool for the job" even within a project. Need a DSL? Write one!
- adsfsdfdsg 5y agoI understand all that. You don't seem to have understood my comment, which was asking questions about the suitability/fitness of the "#lang" mechanism, rather than questioning the idea of polyglot code on top of Racket. I guess it seems to me like it hasn't been established whether the "#lang" mechanism is a brilliant invention, or something cheesy. My initial reaction is that it seems cheesy.
- dTal 5y agoI'm not sure I'm following, then. You think the basic idea of polyglot programming on top of Racket is sound; but that's what #lang does, and is the interesting bit of what we're talking about. The fact that it's specified with a line at the top of the file is a boring implementation detail - albeit the correct decision in my view, since the information about what language a file is written in clearly belongs with that file - exactly the same reason we have shebangs. But it seems like a minor thing to pick on to deem it "not Racket's USP".