Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BLisp: A Statically Typed Lisp Like Language

ytakano.github.io

Post reply on HN
Print view View original

11–20 of 51 posts

Re: BLisp: A Statically Typed Lisp Like Language

#11

Post by valenterry »

threatofrain wrote: post #4
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?

I have never used racket, but what I have seen so far is pretty cool. But for typed Racket, I don't have a good feeling about it either. In particular because it is gradually typed, which kind of defeats the purpose, even though it might be practically useful. But I prefer to have actually compiler guarantees and not just best-effort help.

Re: BLisp: A Statically Typed Lisp Like Language

#12

Post by tines »

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?

For the same reason that it wouldn't be a normal function in any Lisp. The difference is that the macro expander keeps a list of macros (separate from the set of normal functions in the program), so that when it sees a list with a symbol in the first position, it can look up that symbol in its macro list, and if it is a macro, it can call the macro and replace the macro call form with the return value of the macro. Then that gets fed into the evaluator, just like how macros work in any lisp.

Re: BLisp: A Statically Typed Lisp Like Language

#13

Post by valenterry »

tines wrote: post #12
valenterry wrote: post #8

Earlier quoted context omitted.

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

For the same reason that it wouldn't be a normal function in any Lisp. The difference is that the macro expander keeps a list of macros (separate from the set of normal functions in the program), so that when it sees a list with a symbol in the first position, it can look up that symbol in its macro list, and if it is a macro, it can call the macro and replace the macro call form with the return value of the macro. T…

I see, thank you so much for the explanation.

I think to clarify what I said - I didn't mean that static typing and macros are excluding each other. But I think you can either have a sound static type system and highly restricted macros, or less restricted macros but only an unsound type system. That's what I meant with "conflict".

Re: BLisp: A Statically Typed Lisp Like Language

#14

Post by andyferris »

tines wrote: post #2

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?

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.

Re: BLisp: A Statically Typed Lisp Like Language

#15

Post by andyferris »

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?

In some languages they can be, and macro calls are specially marked at the call site instead of (or in addition to) the definition.

But in LISP they are called and expanded implicitly, with the compiler/interpretter keeping track of what's what.

Re: BLisp: A Statically Typed Lisp Like Language

#16

Post by bmitc »

tines wrote: post #2

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?

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

Re: BLisp: A Statically Typed Lisp Like Language

#17

Post by wavegeek »

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…

> (defmacro double (x)

> `(* x x))

Two bugs in two lines. Lisp is indeed a powerful language.

Re: BLisp: A Statically Typed Lisp Like Language

#18

Post by stonewareslord »

wavegeek wrote: post #17
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…

> (defmacro double (x) > `(* x x)) Two bugs in two lines. Lisp is indeed a powerful language.

What are the bugs? I am not familiar with lisp

Re: BLisp: A Statically Typed Lisp Like Language

#19

Post by wk_end »

stonewareslord wrote: post #18
wavegeek wrote: post #17

Earlier quoted context omitted.

> (defmacro double (x) > `(* x x)) Two bugs in two lines. Lisp is indeed a powerful language.

What are the bugs? I am not familiar with lisp

Not OP so there might be others, but the two that I see are:

* most crucially, x isn't actually spliced in, meaning that the macro always literally expands to (+ x x). For example, (+ (double 2) 5) just expands to (+ (+ x x) 5), which will either crash if x is undefined or do something unexpected if x is.

* Even if x were spliced in properly, it gets evaluated twice. That's wasteful at best, and if x has some kind of side effect you (arguably) would get unexpected behaviour - the side effects would run twice.

Re: BLisp: A Statically Typed Lisp Like Language

#20

Post by tluyben2 »

wk_end wrote: post #19
stonewareslord wrote: post #18

Earlier quoted context omitted.

What are the bugs? I am not familiar with lisp

Not OP so there might be others, but the two that I see are: * most crucially, x isn't actually spliced in, meaning that the macro always literally expands to (+ x x). For example, (+ (double 2) 5) just expands to (+ (+ x x) 5), which will either crash if x is undefined or do something unexpected if x is. * Even if x were spliced in properly, it gets evaluated twice. That's wasteful at best, and if x has some kind of…

Yep, see for example [0].

https://www.emacswiki.org/emacs/MacroUtilities

Post reply on HN