BLisp: A Statically Typed Lisp Like Language (opens in new tab)

Another reason for "code as data" is to enable (safe) remote code execution via RPC.

For example you may want to query a database with a custom filter predicate function. If you pass one of BLisp's `Pure` functions across the wire, the database could execute the function with relative safety (compared with using `eval` with a string, or whatever).

I find it frustrating that almost all popular languages lack any safe facility for this, so people have to create some limited query schema (with it's own custom wire encoding and mini-interpretter), or instantiate a sandbox for a non-pure language like Lua and eval a string, or else invent their own fully-blown programming language along the lines of BLisp.

> Since the point of s-expression syntax/homoiconicity is macros

I don't equate S-expressions with macros. S-expressions make many things easier, including: simple and regular but expressive syntax, expressive function and variable names with basically any character sequence allowed, copy and paste-able code that just works, easy automatic code formatting.

> I always feel that for lisp-like languages it's just not a good idea to make them statically typed. Their power is derived from macros and the fact that code is data and the other way around.

I completely agree with the idea that their power is derived from macros, but I vehemently disagree that macros are incompatible with a static type system. The type of a form can be just a simple ADT

    data Form = FInt Int
              | FCons Form Form
              | FNil
              | FString String
              | ...

and a macro is just a function taking Form as arguments and returning a Form. With standard HM type inference, your macros can look exactly like they do in a dynamically typed Lisp. If the backquote is just a reader macro that produces a Form:

    (defmacro double (x)
       `(* x x))

that would be expanded into

    (defmacro double (x)
       (FCons '* (FCons x (FCons x FNil))))

and type inference would determine that the type of double is

    double :: Form -> Form

And destructuring Forms is just normal ADT pattern matching.

Nim is statically typed and has a powerful macro facility:

https://nim-lang.org/docs/manual.html#macros

https://nim-lang.org/docs/macros.html

Seems like you could still have macros, they would just evaluate before type checking. Rust works this way

How do you feel about typed Racket?

Because it’s an effect system, it’s not returning monads. It’s a different kind of type system with different restrictions and benefits. You could make every function implicitly pure, but that would be syntactic sugar, as opposed to Haskell where pure-as-default is a consequence of how the type system is structured.

All functions in Haskell are pure: the function `putStrLn :: String -> IO ()` returns the same IO action for the given input.

It seems to be embedded in Rust: https://github.com/ytakano/blisp#how-to-use

so I would guess interpreted

Lisp isn't necessarily just CL or Scheme. Further, if I recall correctly, ML started out as a lisp that later adopted infix syntax.