"See yeah I'm sure your lisp is cool but my favorite programming language has *pattern matching* baked in"
*Quietly scoops a handful of earth from the ground, squeezes while concentrating for half a second, a pattern matcher falls out, fully formed*
"God damnit this is why everyone hates you guys"
@cwebber honestly I used to think this too, but after spending decades in Clojure where the fact that it's not baked in means that every time you want to do something halfway decent in a new codebase you have to argue with your coworkers about bringing in a third-party library ... it's just not worth the headache of leaving it out of core
racket made the right call; make it built-in, let everyone benefit
just because it's technically possible to do in userspace doesn't mean you should; it's as much a community/convention/style problem as a technical one
@technomancy Yes but your language doesn't need to bottom out in a pattern matcher, and the next time a good idea akin to a pattern matcher is worth exploring, you don't need to extend the core language to explore that idea space
@technomancy That is why Goblins was based on scheme: exploring a new idea space is easy. Lisp is clay.
But I agree of course that having standard libraries is Good, Actually.
@cwebber @technomancy But Racket is far more of a clay than Lisp. #lang is the clay that Lisp wishes it had.
@shriramk @cwebber @technomancy
I remember when #lang was launched and I didn’t understand at the time - it was just shorthand to the module mechanism to me - and that is all the guide says.
Why is it important?
@spdegabrielle @cwebber @technomancy No no, that's not at all what it's about. It's about being able to define and use your own language; it just happens to create modules.
Take a look at the Racket home page [https://racket-lang.org/]. You'll see
#lang typed/racket
#lang scribble/base
#lang datalog
None of those languages is Racket-the-descendent-of-Scheme. Scribble and Datalog have neither a Rackety syntax NOR a Rackety semantics (Scribble infinitely so).
@shriramk @cwebber @technomancy I'm missing the point somehow. How is that different to the languages that target javascript? (Clojurescript, Pyret & TypeScript , etc.)
@spdegabrielle @cwebber @technomancy That's like asking "how's that different from everything running on x86". It's more like the relationship between Clojure and Java.
@shriramk my apologies. I don’t know enough about Clojure[1] (or the diff between jvm and x86) to see the comparison/difference?
I’m not trying to be pigheaded but I do get lost in that particular part of the docs and I can’t make sense of it. [2]
[1] or understand why Clojure lacks a #lang mechanism?
[2] I did find a typo https://github.com/racket/racket/pull/4514
@spdegabrielle @shriramk The Racket tooling lets you access other modules in essentially two ways:
- using the old-style `(module ...)` forms, which essentially let you use the other module as library code, but you can also use whatever other random stuff you feel like `require`ing in, since `module` is provided by racket/base.
- using the `#lang` mechanism which supports a bunch of other features, including changing the reader used for the rest of the file.
@spdegabrielle @shriramk you can think of the `module` approach as like writing C code that lets embed the runtimes of other language's interpreters (Python, Lua, etc), and the `#lang` approach as like writing an executable script with a shebang line that invokes that language's interpreter directly.
@spdegabrielle @shriramk These are in some sense interchangeable - you can do pretty much anything you could do in Python by calling CPython API functions (and there are times when this is even an appropriate thing to do!), but if all Python was was a library of C functions it wouldn't be very interesting and it certainly wouldn't be a "programming language".
@spdegabrielle @shriramk oh, also to be clear, the `#lang` approach doesn't just "support" defining a custom reader, it **requires** you define a reader explicitly (although it's pretty easy to use one of the out of the box ones), and it's the output of that reader which should produce the `(module ...)` form that then gets expanded by Racket's own runtime (in concert with the macros in the `initial-module-path`).
@spdegabrielle @shriramk so while you're submitting documentation PRs on this topic, when you're reading the docs on Module Syntax and get to "6.2.2 The `#lang` Shorthand" the phrase "which reads the same as" between the two sections of example code should really have the word "reads" formatted as code and hyperlinked to https://docs.racket-lang.org/guide/hash-lang_reader.html to be clear that there is a very precise technical definition of "reads" at play
@spdegabrielle @shriramk There's a more in-depth explainer here https://beautifulracket.com/explainer/lang-line.html if you want to point someone else to it.
@elfprince13 @shriramk Thank you for your explanation, I'll admit I'm still getting my head around it - am looking at the beautiful racket link
@spdegabrielle @shriramk Since DrRacket aspires to be an IDE for building programming languages *and* for using those languages after they are built, it makes that it has support for both levels of abstraction.
The best non-shebang-line analogy I can come up with would be if LLVM had an IDE that made it really easy to write compiler frontends *and* to write code in the languages those frontends compiled.