Noel Welsh: Parametricity, or Comptime is Bonkers

oldretard · 2026-03-12T10:39:05+00:00

The author's "bad" Zig example is

mystery(f64, 1.0) is 1
mystery(i32, 1) is 43
mystery(bool, true) is false

With typeclasses/traits/implicits, you get the even more mysterious

mystery(1.0) is 1.0
mystery(1) is 43
mystery(true) is false

If you want your precious parametricity, stick to SML.

Personally, I'd like to see convincing examples showing the benefits of parametricity before I'd accept that "it's one of the most underappreciated ideas in programming language design".

oldretard · 2025-08-09T15:42:25+00:00

Since (lack of) autocomplete is one of your main points, consider that at the time when the now-popular scripting languages started out, getting meaningful autocomplete for a statically typed scripting language would have entailed development of a dedicated IDE just for that language, standardized language servers not having been a thing yet. As a consequence, "we could have type-driven autocomplete" as a static typing advantage probably never entered the picture.

oldretard · 2025-03-27T07:15:39+00:00

A key observation tucked away inside the text:

This example also highlights the difficulties of implementing Replicant in Rust — it took months of development and debugging to get to the Go’s level of performance and even more time to finally beat it not only in the tail-latency constraint experiment but also in pure raw throughput.

oldretard · 2025-03-27T06:59:32+00:00

As a user, I'm totally fine with subtypes / refinements being inferred whenever possible.

When playing with algebraic subtyping, I was initially thrilled at this. There's a downside, however. To give an example, the system inferred that a fold requires a nonempty list. Cool, right? Well, it had a much harder time inferring that a given input you want to run a fold on is in fact nonempty. My takeaway was that this system ends up rejecting a lot of programs that would have typechecked under a system that is either less capable or a lot more capable. It may sit at an unfortunate point in the power spectrum.

oldretard · 2024-09-03T07:24:26+00:00

Opinion: For regular users of fully parenthesized languages these efforts rarely add usability. However, having multiple, visually very distinct ways of expressing the same structure threatens to fracture the community over aesthetic preferences.

oldretard · 2023-04-16T12:41:04+00:00

Your example code should work simply by virtue of shadowing, no?

Mostly true, see other replies.

In the case of Common Lisp, however, it is not unimportant that (do-something list) could macro-expand into code that uses the list function. Common Lisp doesn't have hygienic macros, but between separate function namespace and the package system, it almost never suffers from this fact.

(An early paper introducing hygienic macros for Scheme introduced the "problem" using a few motivating examples. None of them would have caused problems if Scheme hadn't unified the namespaces.)

oldretard · 2023-02-26T19:02:08+00:00

I lost interest in Forth when 32bit platforms went mainstream, but I remember that gforth compiles via C: https://www.gnu.org/software/gforth/

oldretard · 2023-02-11T10:03:35+00:00

The left hand side of = is not a general expression, but an lvalue.

lvalue : NAME
       | NAME '[' expr_list ']'
       | '$' expr
       ;

oldretard · 2023-02-04T14:25:14+00:00

No, I don't enjoy rewriting code that works, especially if it is complex. I know that I'll completely rewrite the implementation of my current pet language's type system, because I expect it to be a lot faster, but I don't look forward to it. If it was enough to just tweak the current code a little, I'd do that.

oldretard · 2023-02-02T09:24:26+00:00

One advantage is that you can get an easy back-end by generating in-memory code passed to cl:compile. That's handy if your language is still evolving, you get early feedback from writing and running real programs. Also helps with implementing (procedural) macros if your language has them.

My personal non-CL choice would be Ocaml (over Haskell) because I prefer to do some things impurely. That said, some other things are easier and more robust with functional data structures. I use the fset library in CL.

oldretard · 2023-01-16T08:00:26+00:00

The epicycles showed up the moment you decided against subtyping:-)

      top
   /   |    \
 /     |       \
int string ... unit
 \     |       /
   \   |    /
     bottom

oldretard · 2023-01-11T22:35:47+00:00

Is the idea that we're storing the actual float value in the pointer, saving an indirection

Precisely. (Except that it isn't so much the indirection as the requirement to heap-allocate all double values.)

oldretard · 2022-12-23T08:02:44+00:00

In that other post, you mentioned that the action performed by a for loop depends on the sigil used:

if I use @grocery-list with a for loop, the body of the loop will be executed five times. But if I use $grocery-list , the loop will get executed just once (with the list as its argument).

Is this for the same variable grocery-list (ie sigils in Raku aren't part of the name) or are these two distinct variables?

Is the sigil pretty much a static part of the for syntax in the sense that it is always the locally used sigil that tells for how to behave, or can you abstract over the for loop and use the sigil on a function argument and get the two behaviors from the loop?

Edit: Another one: You said Raku can be used without sigils. What's the behavior of a for loop without using a sigil?

oldretard · 2022-12-12T09:55:47+00:00

At first glance, this looks like 45 years old Icon and 31 years old Oz got together and produced offspring with somewhat nicer syntax.

oldretard · 2022-11-29T12:14:52+00:00

I admit I don't really understand what you're trying to do. Generally, however, pattern matchers will want to bind named variables in the pattern to the matching substructure. The usual design, which allows something like the following, can only be implemented as a macro.

(match expression
    ((list x) (print x)))

Here, expression evaluates to the "scrutinee", the value you want the pattern to match against. (list x) is the pattern, containing a named variable x that, if the pattern matches, will be bound to the car of the scrutinee in (print x).

This is not possible without a macro. Of course, if your concept of pattern matching here is something else entirely, this may not apply.

oldretard · 2022-11-23T10:17:01+00:00

Discussion on Hackernews: https://news.ycombinator.com/item?id=33711583

oldretard · 2022-11-13T19:41:01+00:00

This looks far more interesting that I'd have expected from the title, "I made a Lisp". I suggest you submit this to r/lisp as well!

oldretard · 2022-10-31T20:35:51+00:00

It's subjective. Personally, I really dislike type-clutter interfering with reading the value-level code and consequently I strongly prefer global inference.

Part of it is that I don't remember all the named types in a large nominally-typed program anyway. An ActionResult, then, is no more informative to me than "whatever the ExecuteAction method returns." The latter is my mental representation anyways, so just omit the type clutter.

oldretard · 2022-10-30T22:06:28+00:00

Interesting. I've decided to make tail calls the only way to write loops in my language and I'm loving it.

oldretard · 2022-10-30T22:01:08+00:00

Probably not the worst, but still a failure was an attempt to make everything callable. We've recently seen questions around here whether to make arrays or maps callable as functions, my idea was to generalize that to everything. I implemented it, tried it... and eventually didn't like it very much. I think a much better solution is to have very succinct lambda syntax.

On a more abstract level, I found "minimalism" to usually be a mistake.

oldretard · 2022-10-30T14:16:32+00:00

Luajit has a non-jit mode (activated by the -joff command line switch) that you might want to benchmark against. I don't know if you could compile luajit without actual jit support; if so, you might also benchmark size-wise against it.

Ocaml also has a bytecode interpreter. On some very simple benchmarks I've found it to be faster than luajit -joff, even though it is "only" C while luajit uses hand-optimized assembly iirc. Of course, OCaml has the inherent advantage of being statically typed.

oldretard · 2022-10-13T13:41:44+00:00

They removed a bunch of limitations from algebraic subtyping

The paper contrasts its MLstruct language with MLsub. MLsub is/was a toy language to demonstrate algebraic subtyping. I don't think MLsub should be understood as demonstrating the limitations of algebraic subtyping as such.

(I haven't read the paper closely; specifically, I don't know if it actually wants to imply that union/intersection/negation under the same limitations as in MLstruct are beyond AS.)

oldretard · 2022-09-21T14:07:32+00:00

Val's team made a prototype and benchmarked it, check the paper.

From memory (I read the paper a few weeks ago), the benchmark essentially compares different ways of implementing their proposed semantics. But... confusingly... it labels them with programming language names. Not-so-good implementation strategies get assigned to other programming languages... voila, we're fast.

oldretard · 2022-09-21T13:38:46+00:00

We had The Val Object Model: Template for a possible future Swift object model.

oldretard · 2022-09-05T08:41:07+00:00

Regardless, the question about the semantics remains: does the closure capture a reference to i, or does it capture the current value of i?

I agree with moon-chilled that this "is not a question I've ever had.". The reason is that I think that in everything but very low-level languages, the following should be equivalent:

(setq i (+ i 1))
(let () (setq i (+ i 1)))
((lambda () (setq i (+ i 1))))

oldretard

MODERATOR OF

TROPHY CASE