alex_muscar

This goes at least as far back as anaphoric macros: https://en.m.wikipedia.org/wiki/Anaphoric_macro.

Just curious who pays for cleaning up the debris after one if these landings.

The part where he asserts indexing should start at zero is this:

> Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i < N+1; starting with 0, however, gives the nicer range 0 ≤ i < N. So let us let our ordinals start at zero: an element's ordinal (subscript) equals the number of elements preceding it in the sequence.

"A nicer range." This is just Dijkstra's preference.

Interestingly, he links ordinals (the subscript) to cardinals (how many numbers there are before the element).

The off by one is just as likely in both schemes with half open intervals.

The nice property of the length of the sequence falling "for free" from the indices is not essential if you track the length separately. While it was important in the age of machines with severely constrained memories, the downsides outweigh the merits.

That is just untrue. Compilers tend to generate better code for imperative algorithms because current architectures implement a fundamentally imperative model. Yes, "sufficiently advanced" compilers can generate code that has similar performance to imperative algorithms from functional ones. But that requires some heavy lifting static analysis and optimisation passes. Have a look here: https://godbolt.org/z/sPT3snWE4. Only if you remove `#[inline(never)]` from `add1` will you get efficient code for the functional algorithm. This is a trivial example, but it ilustrates some of the nuances.

Knuth's original article is a good starting point: http://literateprogramming.com/knuthweb.pdf.

Knuth's Programming Pearls entries are good reading as well.

I was playing around with SPARC assembly and realised that implementing coroutine linkage can turn out quite elegant.

It kind of resembles Knuth's MMIX.

I've had OK experiences with alibris. Based in UK though.

Someone on the D subreddit pointed that out as well. I didn't know it was available at compile time. I'll update the post. Thanks.

That's right. The Cobol version has its own beauty because it's built into the language. Also, this is my TIL nugget of the day. Thanks :)

Where I use D's metaprogramming capabilities to generate a binary search function using Shar's algorithm.

Glad to hear that. Brian Kernighan said that he was thinking of updating the AWK book on numberphile last year. Looking forward to it as well :)

That's a nice project idea. Made me try it in common lisp which comes with a compiler built in. It's fairly doable. The only downside is the big executable sizes for SBCL and CCL, and the relatively slow startup times for ECL.

I think GNU grep does something similar. When it has a fixed patter it uses Boyer-Moore [1].

[1]: https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...

Nice work. I don't think people appreciate just how much work has been put into this project.

Thank you!

> Would there be enough interest in having these letters in searchable form to motivate the effort?

Yes, please :). Esp. Dijkstra's letter from the 5th of Apr '79. It's a bit hard to read.

Thanks for making them available.

I cannot upvote you enough.

Yes, that is do-able, if they want to make this change.

I didn't say constructor arguments don't have tuple semantics :). In OCaml tuples are a "unit", i.e. you can't use (,) as an operator. In that sense they match with the constructor semantics: it needs all its arguments at once. It's the constructors not being functions that I was complaining about. Also, I'd say that capitalisation alone is not enough to compensate for constructors looking like they're curried functions. But that's just a matter of taste.

Nice to see that OCaml is getting so much love at facebook. Unfortunately, adding a new syntax that's almost OCaml, but not quite, doesn't seem like such a great idea. While it might make the language accessible to more people, it runs the risk of fragmenting the community.

I know syntax is subjective, but some of the choices seem a bit odd. For example, declaring variants and using their constructors looks like Haskell, but the semantics is still OCaml. In Haskell, constructors are first order so they can be passed as functions, and partially applied. It makes sense that their declaration and use looks like function declaration and function calls. In OCaml they are not first class, that is, you can't pass the as arguments, or partially apply them. That's why it makes sense for the declaration to look like a tuple, and the use to look like a function applied to a tuple--well, somewhat, you can still argue that it's still confusing because you might expect to be able to apply the constructor to a tuple variable, but well, such is life :). Unless constructors are first class in Reason--it doesn't look like it from a quick scan through the docs--this particular syntactic difference is of dubious value, and, worse, it can be misleading to newcomers.

Also, changing `match` to `switch` seems gratuitous as well, and it also loses some of the meaning of the original. i.e. "I want to match this value against this set of patterns".

Finally, I know that using `begin` and `end` for blocks is verbose and Pascal-ish--which people seem to hate for some reason--but using { } for scopes looks out of place, and leads to awkward cases like this:

    try { ... } { | Exn => ... };

I don't mean for this to sound ranty, or like I'm picking on Reason. I think it's good that facebook is tryiog to spice things up in the OCaml community.

This is a really neat book. The fact that it builds a complete compiler and virtual machine in ~100 pages is really amazing.

I wouldn't say it's a language war :) The communities of D, C++ and Rust seem quite civil.

This looks really interesting. I'll give it a go :)

Subtyping polymorphism

Your approach does not support polymorphism.

Your point about programmers having favourite editors (which I consider valid) contradicts the point you made about an important part of your audience being middle/high schoolers, which I don't think have such strong preferences towards one editor or another. It seems to me that you are making compromises to cater to the needs of an audience which is much broader than that you have identified for the language.

It would be a shame to compromise the design of an interesting language just because the target audience is not clearly defined.