Live data from Hacker News

Crunch – a Scheme compiler with a minimal runtime

more-magic.net

61–70 of 73 posts

Re: Crunch – a Scheme compiler with a minimal runtime

#61
post #30

Earlier quoted context omitted.

What are the main differences between OcamML and a statically typed Lisp?

Type inference is probably the biggest thing. You would need explicit "phases" to expand macros, disallow macro expansion at runtime, and implement bi-directional type inference HM-style to get even close to what OCaml has. To be honest, I'd kill for a Lisp that had the same type system as OCaml, but I suspect the closes we'll get is basically Rust (whose macro system is quite good).

https://github.com/LuxLang/lux

    The language is mostly inspired by the following 3 languages:

    Clojure (syntax)
    Haskell (functional programming)
    Standard ML (polymorphism)

Re: Crunch – a Scheme compiler with a minimal runtime

#62
post #52
post #8

For Common Lispers such as myself, who are vaguely aware of developments in the Scheme space: the most important difference between CRUNCH and Chicken appears to be that, while both compile down to C/object code, CRUNCH is additionally targeting a statically-typed subset of Scheme. Opinion: this is great. The aversion of Lispers to static types is historical rather than intrinsic and reflects the relative difference…

I don't believe it's not intrinsic. A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. Lisp programmers don't want to be told what to do, especially by the compiler. Some CLs like SBCL have allowed some form of inference through the standard type declarations in the language. This leads me to believe that the 'right thing' in the case…

> A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system.

This perceived inflexibility is what my comment was getting at - that for primitive type systems available back in the 80's, yes, the types significantly constrained the programs you could write. With today's type systems, however, you have far more flexibility, especially those with "Any" types that allow you to "punch a hole in the type system", so to speak.

When I tried typed Python a few years ago, I found out that, to my surprise, 99% of the code that I naturally wrote could have static types attached (or inferred) without modification because of the flexibility of Python's type system.

I also learned that types are a property of programs, more than just languages. If a program is ill-typed, then having a dynamically-typed language will not save you - it will just crash at runtime. Static types are limiting when either (1) they prevent you from writing/expressing well-typed programs because of the inexpressiveness of the type system or (2) it's burdensome to actually express the type to the compiler.

Modern languages and tools present massive advances in both of those areas. Type systems are massively more expressive, so the "false negative" area of valid programs that can't be expressed is much, much smaller. And, with type inference and more expressive types, not only do you sometimes not have to express the type in your source code at all (when it's inferred), but when you do, it's often easier.

The "Any" type is really what steals the show. I don't think that there's a lot of value in a fully statically-typed Lisp where you can't have dynamic values at all - but I think there's a lot of value in a Lisp with a Python-like type system where you start out static and can use "unknown", "any", and "object" to selectively add dynamic types when needed.

Because, being a Lisper, you probably think like me, I'll give you the idea that really convinced me that types are positive value (as opposed to "only" being small negative value): they enable you to build large, complex, and alive systems.

Types are a force-multiplier for our limited human brains. With types, you can more easily build large systems, you can more easily refactor, you can start with a live REPL and more easily transition your code into source on disk. Types help you design and build things - which is why we use Lisps, after all!

Re: Crunch – a Scheme compiler with a minimal runtime

#63
post #62
post #52

Earlier quoted context omitted.

I don't believe it's not intrinsic. A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. Lisp programmers don't want to be told what to do, especially by the compiler. Some CLs like SBCL have allowed some form of inference through the standard type declarations in the language. This leads me to believe that the 'right thing' in the case…

> A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. This perceived inflexibility is what my comment was getting at - that for primitive type systems available back in the 80's, yes, the types significantly constrained the programs you could write. With today's type systems, however, you have far more flexibility, especially those wit…

I don't disagree with you there. The only thing CL really misses out on is that its type system isn't specced out enough to be as powerful as it could be. Since they're just macros you can write all kinds of crazy types, but non-terminating ones just might not work if your implementation doesn't handle them a certain way. This was actually a disputed issue: https://www.lispworks.com/documentation/HyperSpec/Issues/iss....

Someone had proposed reifying types to be first-class objects, which might be a good thing. I haven't thought about it enough to decide. https://gist.github.com/Bike/e405cc49a64fed0752b524c292bd715...

Re: Crunch – a Scheme compiler with a minimal runtime

#64
post #52

Earlier quoted context omitted.

I don't believe it's not intrinsic. A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. Lisp programmers don't want to be told what to do, especially by the compiler. Some CLs like SBCL have allowed some form of inference through the standard type declarations in the language. This leads me to believe that the 'right thing' in the case…

I want static types in a higher level assembly language for systems programming. That's because I want to work with machine-level representations, in which there are no spare bits for indicating type at run-time (moreover, using such a language, we can design a type system with such bits, in any way we please). I don't want static types in a high level language. It's just counterproductive. We only have to look at nu…

Oh come on, sum types are so much more useful than a value which can have literally any type (including undefined aka nil).

Re: Crunch – a Scheme compiler with a minimal runtime

#65
post #46

Earlier quoted context omitted.

Type inference is probably the biggest thing. You would need explicit "phases" to expand macros, disallow macro expansion at runtime, and implement bi-directional type inference HM-style to get even close to what OCaml has. To be honest, I'd kill for a Lisp that had the same type system as OCaml, but I suspect the closes we'll get is basically Rust (whose macro system is quite good).

There is a simpler solution than type inference to removing type annotations while retaining types: remove the distinction between variable and type names. The way that you handle multiple instances of a type is to define an alias for the type. In pseudocode it might look like: type Divisor Number def divide(Number, Divisor) = Number / Divisor As compared to: def divide(number: Number, divisor: Number) = number / Div…

Is that language a Forth dialect by any chance?

Re: Crunch – a Scheme compiler with a minimal runtime

#67

> Other targets are possible, like GPUs. I don't know anything about that, so if you are interested and think you can contribute, please don't hesitate to contact me. The freestanding macro suggests most of the heavy lifting is done. Stuff the GPU targets will struggle with in no particular order: - setjmp / longjmp - signals (if used?) - threads - fast alloc/free - stack will be smaller than chicken expects I don't…

Crunch doesn't have any of these. That's CHICKEN you're thinking of, but CRUNCH explicitly does not require CHICKEN.

Re: Crunch – a Scheme compiler with a minimal runtime

#68
post #62
post #52

Earlier quoted context omitted.

I don't believe it's not intrinsic. A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. Lisp programmers don't want to be told what to do, especially by the compiler. Some CLs like SBCL have allowed some form of inference through the standard type declarations in the language. This leads me to believe that the 'right thing' in the case…

> A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. This perceived inflexibility is what my comment was getting at - that for primitive type systems available back in the 80's, yes, the types significantly constrained the programs you could write. With today's type systems, however, you have far more flexibility, especially those wit…

Being able to declare types is the reason why I switched from Scheme to Common Lisp. It's just a shame that there's basically no concept of generic types and 'satisfies' isn't quite good enough to make up for it.

Re: Crunch – a Scheme compiler with a minimal runtime

#69

Earlier quoted context omitted.

There isn’t much demand for Lisps in general.

I think given the sheer amount of them that is demonstrably false

Have you used one at work? I would surely love to but haven’t had the chance yet.

Re: Crunch – a Scheme compiler with a minimal runtime

#70

Earlier quoted context omitted.

I think given the sheer amount of them that is demonstrably false

Have you used one at work? I would surely love to but haven’t had the chance yet.

Clojure is fairly popular (I'm using it at work, though I'd prefer Scheme of course)
Post reply on HN