soegaard

There is a reason for that.

Consider appending two strings in Scheme:

    (string-append s1 s2)

Appending two strings in Scheme:

    (vector-append v1 v2)

Since the type is present in the function name, it would be redundant to include it in the variable name.

You need to use the Racket documentation.

See https://docs.racket-lang.org/reference/quasiquote.html#%28fo...

    > `(1 ,@2)
    '(1 . 2)

This is a pair. The notations is called "dotted pair".

I am not 100% sure what's going on, but you can use `read` mode this way:

    #lang racket
    (let ((a (read (open-input-string "#0=(0 . #0#)"))))
      (display (car a)))

I think the problem is that `read` / `write` support shared data constructed using `shared`. But programs (read by `read-syntax` are not allow to have cycles.

That has been in Racket for a long time.

You will like:

https://parentheticallyspeaking.org/articles/bicameral-not-h...

The evolution of the logo:

https://users.cs.northwestern.edu/~robby/logos/

The skull didn't last long.

> Easy is an understatement. Macros and dynamic programming (often done using runtime reflection in other languages) are so trivially easy in Lisps that one can stumble into it without realizing they're even doing it.

Well, getting the interaction between modules and syntax transformations (macros) right is not an easy task.

"Composable and Compilable Macros: You Want it When?" Matthew Flatt http://dl.acm.org/authorize?24908

Btw - if people are interested in Racket related blogs / articles etc.

https://racket-stories.com/

Yeah - the number syntax is pretty cool.

    #i is the prefix for inexact
    #e is the prefix for exact

So `#e0.1` is exact 0.1 which means it will be read as an exact fraction 1/10 and `#i0.1` will be read as a floating point number.

The `i` in `8i` is the imaginary unit. The `1@1` is the polar notation for complex numbers.

The `10#` is a compatibility remain (the Scheme authors wanted a way to see how many signifant digits were known. In `10#` there 2. So `#` stands for "some digit". In most implementations this is read as 0. More details at [1]

An `#` followed by a list datum is read as a vector. Thus `#()` is an empty vector and `()` is an empty list.

[1] https://stackoverflow.com/a/10936403/23567

Complicated? Well, to support both inexact (floating point) and exact numbers (bignums and fractions) it makes sense to have `#i` and `#e` to explicitl choose. The default is (more or less): numbers with . are inexact the others are exact.

> DrRacket seems to have doing the thing where they implement of a bunch of GUI stuff from scratch ...

The GUIs actually use the underlying native GUIs thanks to the dynamic FFI. The goal is to have a cross platform GUI. Your program runs on macOS, Linux and Windows without any problems.

But if there is some gui feature, that is only available on one platform, you won't find it in the builtin gui libraries. However, you can always add platform specific functionality yourself.

The email is obfuscated.

https://pkgs.racket-lang.org/

And has been for a long while.

As most other things - you get used to it.

But it's important to note, at you need editor support for rendindenting blocks easily and correctly.

Notice that Racket now supports "tree lists".

https://docs.racket-lang.org/reference/treelist.html

Fear not, you can make `#%top` and `#:app` rewrite `foo:` to `#:foo`.

FWIW choosing `#:foo` over, say, `foo:` was due to backwards compatibility. In Scheme and Racket `foo:` is a legal identifier, so there might have been programs that stopped working, if `foo:` suddenly was a keyword.

It was running an old version of BC.

I can't remember the details, but I recall that Arc was pinned to an older version of Racket and didn't benefit from improvements to BC and then later to CS.

But ... be aware that the Arc interpreter is much more dynamic than Racket, so in general normal Racket programs are more efficient than Arc programs.

In DrRacket mark the section (with shift+arrows) then use tab or shift+tab.

Looks like a real conference - but the first thing you see is a large image of Rick Astley ?!

> I LOATHE the fact that you traverse lists and vectors in completely different ways

In Racket:

    (for ([x xs]) (displayln x))

This works for `xs` being a sequence, which includes lists and vectors.

Making the type explicit generates faster code:

    (for ([x (in-list   xs)]) (displayln x))
    (for ([x (in-vector xs)]) (displayln x))

The version Microsoft used is discontinued. However, you can just buy a license of the new product.

https://www.wiris.com/en/mathtype/

Agree. It got the ball rolling.

Don't you need parens here?

    (local.get 0)
    (local.get 1)

FWIW if you are looking for examples of WebAssembly written in the textual format, take a look at:

https://raw.githubusercontent.com/soegaard/webracket/refs/he...

As a small example, here is a definition of `$car` which extracts the first value from a pair.

    (func $car (type $Prim1) 
               (param $v (ref eq)) 
               (result (ref eq))
      (if (result (ref eq)) 
          (ref.test (ref $Pair) (local.get $v))
          (then (struct.get $Pair $a (ref.cast (ref $Pair) (local.get $v))))
          (else (call $raise-pair-expected (local.get $v))
                (unreachable))))

This was a great article and inspired me to add support for binary files in `peek`.

https://soegaard.github.io/peek/#%28part._binary-files%29

For me the key insight is that similar values should get similar colors. And since Fx and 0x are "similar" the color palette should be cyclic.

Yes.

Skim

https://andykeep.com/pubs/dissertation.pdf

Also see the this text:

https://www.cs.umd.edu/class/fall2025/cmsc430/Notes.html

Nanopass uses structures internally to represent the programs.

The Nanopass dsl just gives the user a nicer syntax to specify the transformations.

An Incremental Approach to Compiler Construction

Abdulaziz Ghuloum

http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

Abstract

Compilers are perceived to be magical artifacts, carefully crafted by the wizards, and unfathomable by the mere mortals. Books on compilers are better described as wizard-talk: written by and for a clique of all-knowing practitioners. Real-life compilers are too complex to serve as an educational tool. And the gap between real-life compilers and the educational toy compilers is too wide. The novice compiler writer stands puzzled facing an impenetrable barrier, “better write an interpreter instead.”

The goal of this paper is to break that barrier. We show that building a compiler can be as easy as building an interpreter. The compiler we construct accepts a large subset of the Scheme programming language and produces assembly code for the Intel-x86 architecture, the dominant architecture of personal computing. The development of the compiler is broken into many small incremental steps. Every step yields a fully working compiler for a progressively expanding subset of Scheme. Every compiler step produces real assembly code that can be assembled then executed directly by the hardware. We assume that the reader is familiar with the basic computer architecture: its components and execution model. Detailed knowledge of the Intel-x86 architecture is not required.

The development of the compiler is described in detail in an extended tutorial. Supporting material for the tutorial such as an automated testing facility coupled with a comprehensive test suite are provided with the tutorial. It is our hope that current and future implementors of Scheme find in this paper the motivation for developing high-performance compilers and the means for achieving that goal.

I misread it too.