
Racket 7.3 - jessealama
https://download.racket-lang.org/v7.3.html
======
Labo333
I am really excited by Racket.

Unlike most minimalist LISP languages with a community of individual hackers
who each have their own macros and packages, this one is battery included
while still being the most flexible with the #lang header. Seriously, it comes
with awesome data structures (actuelly more than Python).

The only thing that prevents me from using it as much as Python or C++ is the
lack of tools for major editors. DrRacket is NOT ok, I would like a langserver
and vscode extension so badly! When I have a bit of free time and have
finished other projects with a higher priority, I'll definitely give it a try.
(yes I'm aware there are some langservers but none of them is really
production ready)

~~~
Veen
Emacs has a decent Racket mode with most of the functionality of DrRacket.

~~~
soegaard
These days racket-mode for Emacs is more than decent!

Could wish for similar modes for SublimeText and VisualCode though.

~~~
cercatrova
[https://marketplace.visualstudio.com/items?itemName=evzen-
wy...](https://marketplace.visualstudio.com/items?itemName=evzen-
wybitul.magic-racket)

For VSCode

------
nerdponx
And yet I'm still too stupid to understand the macro system. Oh well.

I also didn't know there was a Chez version. Racket already has a native AOT
compiler, right? What would the advantage be to run on Chez, faster or smaller
compiled code?

~~~
jim-jim-jim
Is it the general Scheme syntax-rules macros that you're struggling with? Or
something unique to Racket? (which I haven't used)

If it's the former, I found this little article helpful when I was new to
Scheme:

[http://www.willdonnelly.net/blog/scheme-syntax-
rules/](http://www.willdonnelly.net/blog/scheme-syntax-rules/)

~~~
tgbugs
For Racket specific macro tooling syntax-parse [0] in combination with syntax
classes is usually the suggested starting point. Hygenic with pattern matching
and a bunch of other features for parsing s-expression grammars. As mentioned
down-thread Greg Hendershott's Fear of Macros [1] is a good starting point for
a number of folks. The curriculum for Racket School 2018 [2] also has
exercises that help introduce the syntax-parse tooling.

0\. [https://docs.racket-
lang.org/syntax/Parsing_Syntax.html](https://docs.racket-
lang.org/syntax/Parsing_Syntax.html) 1\.
[https://www.greghendershott.com/fear-of-
macros/](https://www.greghendershott.com/fear-of-macros/) 2\. [https://summer-
school.racket-lang.org/2018/plan/](https://summer-school.racket-
lang.org/2018/plan/)

------
lenkite
I really wish there was a standard Scheme that compiled to native for all
desktop and mobile OS'es and also supported multi-threading. Does anyone know
about one ?

~~~
rgrau
LambdaNative is a cross-platform development environment written in Scheme,
supporting Android, iOS, BlackBerry 10, OS X, Linux, Windows, OpenBSD, NetBSD,
FreeBSD and OpenWrt.

[http://www.lambdanative.org/](http://www.lambdanative.org/)

~~~
lenkite
LambdaNative is a wrapper and abstraction over Gambit Scheme. It does not
support multi-core threading.

~~~
rgrau
Well, that was my best shot :(. I'm sorry I don't have an answer then.

You were asking for threads, and gambit has lightweight threads, so I assumed
there was a way to use them via ln. Multi-core threading is a different story
though.

~~~
lenkite
Yes, it's a bit of a pity that great functional languages like Scheme and even
the veteran common LISP are loosing out to modern languages like Kotlin
because of lack of support in these critical, functional areas. Especially
when REPL based development is so _amazingly_ productive.

~~~
fiddlerwoaroof
Common Lisp has real threading with a standardized interface via Bordeaux-
threads and, with some limitations runs on most of the desktop and mobile
operating systems one would expect (the limitation being that most workflows
have you write the GUIs in a different language and then call into CL,
although EQL is an exception to this rule:
[https://www.cliki.net/EQL](https://www.cliki.net/EQL)

~~~
NikkiA
Does EQL still depend on smoke like common-qt does? Because smoke is so
deprecated now that I simply gave up trying to get it to build common-qt on a
recent distro.

~~~
fiddlerwoaroof
I don’t think so, it’s built on ECL, so the lisp is compiled to C and then
linked to Qt. However, I’m not sure how all the details work.

~~~
fiddlerwoaroof
And, there’s a qt5 version.

------
bjourne
Is typed racket still very slow? I'm interested in hearing how Racket's
gradual typing works.

~~~
chriswarbo
Typed racket isn't slow (as far as scripting languages go). Maybe you're
thinking of Racket's "contract" system?

AFAIK typed racket does type-checking during compilation (via raco); the
resulting code is no slower than normal Racket, although I'm not sure if it's
faster either.

The contract system is different; it works on normal, untyped Racket code and
performs checks at runtime; similar to using Python decorators to check the
input and output of a function. This slows things down, so it's recommended to
only check things at module boundaries. For example:

    
    
        #lang racket
        (require racket/contract)
        (require racket/match)
        (provide factorial)
    
        (define/contract (factorial n)
          (-> exact-nonnegative-integer?
              exact-nonnegative-integer?)
          (fact n))
    
        (define (fact n)
          (match n
            [0 1]
            [_ (* n (fact (- n 1)))]))
    

This module exposes the `factorial` function, which checks (at runtime)
whether its argument and return value are non-negative integers (i.e. 0, 1, 2,
...). The actual calculation is done by the `fact` function, which is private
and doesn't do any checks. If we don't separate the checks from the
calculation, we would end up running the checks on every recursive call, which
would slow things down a lot.

As far as I'm aware, Racket's gradual typing is done by contracts at the
interface between typed and untyped code. Hence it's not that typed racket is
slow, it's that passing untyped values into typed functions can be slow, if we
want accurate blame information for errors.

~~~
bjourne
I'm referring to Takikawa et al (2016), who reported performance 50-100 times
worse performance numbers by mixing typed and untyped Racket code together.
Actually 100 times slower execution. They used type annotations on the module
level. Would be interesting to know if Racket developers have proven them
wrong and if so, how.

[http://www.ccis.northeastern.edu/home/types/publications/gra...](http://www.ccis.northeastern.edu/home/types/publications/gradual-
dead/pre-treatment.pdf)

~~~
maxiepoo
Just to make it clear, the authors of that paper (including myself) are all to
some extent Racket developers. Some big improvements have been made but there
are still pathological cases. For the latest published on this see this paper:
[http://users.cs.northwestern.edu/~robby/pubs/papers/oopsla20...](http://users.cs.northwestern.edu/~robby/pubs/papers/oopsla2018-fgsfs.pdf)

But also it's important to note that it's not Typed Racket or Racket in
isolation that are slow, but the inter-mingling of the two due to contract
overhead.

------
stesch
Font looks like shit in Firefox on macOS X.

~~~
Veen
For reasons I find difficult to understand, the text is between <pre> tags and
uses a monospace font (Inconsolata). It is curious that a project that cites
Matthew Butterick as a contributor should make such poor decisions about
typography, especially when the rest of the documentation is above average in
that area.

~~~
dragonwriter
It's wrapped in <pre> tags because it is preformatted text of the type that
would be used in email, etc., announcements (probably becauae it's the exact
text from those media, without transformation), so not using <pre> would lose
significant formatting.

Of course, the formatting is broken anyway, because two of the continuation
lines of bullet-pointed lines are underindented by one space.

~~~
stesch
Making the font bold is what makes it look so bad in Firefox. In combination
with the font.

