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

Typed Lisp, A Primer (2019)

alhassy.com

Post reply on HN
Print view View original

1–10 of 31 posts

Re: Typed Lisp, A Primer (2019)

#3

Post by runevault »

I've been thinking about typed lisp a bit lately since I started messing with CL again, and I admit the point about lists as code hadn't crossed my mind as something you have to deal with for any typing attempts. If you tried to make a "fully static typed lisp" likely you'd need a few holes for areas like that where they don't make sense. Well that or do the shenanigans things like c# do for param arrays where it is just an array of objects.

Mind you I feel like over time we are seeing dynamic and static typing converging more and more. Python type annotations are a thing to some degree I know, while c# a while back added the dynamic type.

Re: Typed Lisp, A Primer (2019)

#5

Post by throwaway17_17 »

runevault wrote: post #3

I've been thinking about typed lisp a bit lately since I started messing with CL again, and I admit the point about lists as code hadn't crossed my mind as something you have to deal with for any typing attempts. If you tried to make a "fully static typed lisp" likely you'd need a few holes for areas like that where they don't make sense. Well that or do the shenanigans things like c# do for param arrays where it is…

Can you explain what you mean by ‘holes for areas like that’? I assume the area you are referring to is lists as code, but I don’t understand what you are saying by claiming there needs to be a hole for it.

Re: Typed Lisp, A Primer (2019)

#6

Post by thesz »

runevault wrote: post #3

I've been thinking about typed lisp a bit lately since I started messing with CL again, and I admit the point about lists as code hadn't crossed my mind as something you have to deal with for any typing attempts. If you tried to make a "fully static typed lisp" likely you'd need a few holes for areas like that where they don't make sense. Well that or do the shenanigans things like c# do for param arrays where it is…

One can have types for lists as if they are constructed for code and for data. If type is valid for code, you can use it as code. If type is valid for data, you can use it as data.

There should be no holes, but non-determinism.

Re: Typed Lisp, A Primer (2019)

#7

Post by runevault »

throwaway17_17 wrote: post #5
runevault wrote: post #3

I've been thinking about typed lisp a bit lately since I started messing with CL again, and I admit the point about lists as code hadn't crossed my mind as something you have to deal with for any typing attempts. If you tried to make a "fully static typed lisp" likely you'd need a few holes for areas like that where they don't make sense. Well that or do the shenanigans things like c# do for param arrays where it is…

Can you explain what you mean by ‘holes for areas like that’? I assume the area you are referring to is lists as code, but I don’t understand what you are saying by claiming there needs to be a hole for it.

By a hole I mean places where it doesn't require strict typing. For example in most static languages everything is typed to some degree. Some cases they abuse things like "just make it an object" but to me that has always felt an unfortunate hole that I wish wasn't necessary but I dunno how you get around some form of it in cases like param arrays or this code as data issue.

Re: Typed Lisp, A Primer (2019)

#9

Post by runevault »

vindarel wrote: post #4

> Augment Lisp with functional Haskell-like type declarations ;-) Since the article's publication, this is now possible with the industrial-grade Coalton: https://github.com/coalton-lang/coalton/

Oh hey I'll have to look at this at some point, luckily I'm already using SBCL for my re-learning.

Re: Typed Lisp, A Primer (2019)

#10

Post by cjbgkagh »

runevault wrote: post #3

I've been thinking about typed lisp a bit lately since I started messing with CL again, and I admit the point about lists as code hadn't crossed my mind as something you have to deal with for any typing attempts. If you tried to make a "fully static typed lisp" likely you'd need a few holes for areas like that where they don't make sense. Well that or do the shenanigans things like c# do for param arrays where it is…

AFAIK a hole is the usual term for the spot for a generic parameter. Sounds like you want a Top which the Any type.
Post reply on HN