BLisp: A Statically Typed Lisp Like Language

#1

Post by agentofuser » Sat, Jun 26, 2021, 11:26 AM UTC

BLisp: A Statically Typed Lisp Like Language
ytakano.github.io

Re: BLisp: A Statically Typed Lisp Like Language

#2

Post by tines » Sun, Jun 27, 2021, 11:28 PM UTC

Since the point of s-expression syntax/homoiconicity is macros, I'm surprised to not see any mention of them in the feature list linked here. Does BLisp support macros? If so, what kind?

Also, is there an example of the type inference working?

Re: BLisp: A Statically Typed Lisp Like Language

#3

Post by valenterry » Mon, Jun 28, 2021, 12:59 AM UTC

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.

For statically typed languages, they only feel ergonomic to me if they have highly specialized syntax and if they really leverage the type-system (which is often in conflict with macros and runtime flexibility).

Re: BLisp: A Statically Typed Lisp Like Language

#4

Post by threatofrain » Mon, Jun 28, 2021, 1:06 AM UTC

valenterry wrote: post #3

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. For statically typed languages, they only feel ergonomic to me if they have highly specialized syntax and if they really leverage the type-system (which is often in conflict with macros and runtime flexibility).

How do you feel about typed Racket?

Re: BLisp: A Statically Typed Lisp Like Language

#5

Post by brundolf » Mon, Jun 28, 2021, 1:33 AM UTC

valenterry wrote: post #3

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. For statically typed languages, they only feel ergonomic to me if they have highly specialized syntax and if they really leverage the type-system (which is often in conflict with macros and runtime flexibility).

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

Re: BLisp: A Statically Typed Lisp Like Language

#6

Post by tines » Mon, Jun 28, 2021, 1:34 AM UTC

valenterry wrote: post #3

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. For statically typed languages, they only feel ergonomic to me if they have highly specialized syntax and if they really leverage the type-system (which is often in conflict with macros and runtime flexibility).

> 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.

Re: BLisp: A Statically Typed Lisp Like Language

#7

Post by xixixao » Mon, Jun 28, 2021, 1:43 AM UTC

Why require Pure to be an annotation - why not make that the default without annotation - no effects? (Same as in Haskell)

Re: BLisp: A Statically Typed Lisp Like Language

#8

Post by valenterry » Mon, Jun 28, 2021, 2:52 AM UTC

tines wrote: post #6

valenterry wrote: post #3

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. For statically typed languages, they only feel ergonomic to me if they have highly specialized syntax and if they really leverage the type-system (which is often in conflict with macros and runtime flexibility).

> 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 | FCo…

> and a macro is just a function taking Form as arguments and returning a Form

Why would it not just be a normal function then?

Re: BLisp: A Statically Typed Lisp Like Language

#9

Post by nerdponx » Mon, Jun 28, 2021, 2:53 AM UTC

valenterry wrote: post #8

tines wrote: post #6

Earlier quoted context omitted.

> 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 | FCo…

> and a macro is just a function taking Form as arguments and returning a Form Why would it not just be a normal function then?

Because it's evaluated at compilation time.

Re: BLisp: A Statically Typed Lisp Like Language

#10

Post by valenterry » Mon, Jun 28, 2021, 2:54 AM UTC

brundolf wrote: post #5

valenterry wrote: post #3

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. For statically typed languages, they only feel ergonomic to me if they have highly specialized syntax and if they really leverage the type-system (which is often in conflict with macros and runtime flexibility).

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

To my knowledge, Rust's macros are not generally safe/sound by definition. And that can be a big problem down the line. Compare it to Scala. When they developed Scala 3, they changed macros and dropped a lot of their powers to make the safe/sound by definition and compatible with the typesystem. But they are now severely restricted when compared to Lisp macros.

EDIT: here's an example of a discussion about that in Rust: https://github.com/rust-lang/unsafe-code-guidelines/issues/2...