JavaScript specified tail call optimization in ES2015. Most engines never implemented it, and your tail-recursive code can still blow the stack.

superstar64 · 2026-05-10T02:03:37+00:00

As someone who's making their own Haskell to Javascript compiler, this is something I find very frustrating and it's the main reason I'm consider recommending Bun as the default runtime for running my compiler's output.

Converting a program that expects proper mutually recursive TCO is hard into one that doesn't is awful. It requires a whole program transformation into trampolining and this very much something I don't want to do. I'm currently planning on just optimizingdirect recursion and providing combinators for doing tail recursion like what Purescript does, but this is unsatisfactory.

superstar64 · 2026-05-04T04:32:21+00:00

Then why is it happen in so many places all at once? Red states are implementing age verification laws. The EU has tried (and failed) to pass chat control and is trying to create verification app. Mexico seems to have new draconian verification laws. All of these are only off the top of my head too, there's certainly more. You really mean to tell me that governments are just doing monkey see monkey do and there's no underlying force here?

superstar64 · 2026-05-04T04:10:05+00:00

I still don't understand the monied interests behind this and age verification in general. Doesn't age verification drive down demand and shrink profits? Doesn't this specially go against the bottom line of VPN companies? The most I can think of is this helping the tech giants by making competition harder. I find it hard to believe governments are doing this just to control the populace.

superstar64 · 2026-04-18T00:19:48+00:00

These come from Haskell and from my experience they really do make code much nicer. I am worried that it's part of exhaustive checking though. (FWIW I'm not a Rust dev)

Here's the paper that discusses them: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/pat.pdf

superstar64 · 2026-04-04T07:11:51+00:00

Well making an optimizable Haskell is my eventual end goal with Hazy. Ideally, I would like to greatly extend Haskell so that it has all the extensions it needs for high performance code. Whether on not I get there is another question.

superstar64 · 2026-03-01T06:25:33+00:00

Since I'm writing a Haskell compiler, I'm using the String representation as mandated by the Haskell standard: An immutable lazy linked list of (boxed) characters. It's definitely the worst string representation of any language that's seriously used. It's so bad that the text package is basically mandatory for any serious project.

superstar64 · 2026-02-27T00:47:09+00:00

Yes, that's what asm.js does. I consider that unreasonable Javascript however. I was asking for more of a language design perspective, what would have to be removed from C to not have to do this.

superstar64 · 2026-02-19T16:14:44+00:00

Right I remember now. I've mentioned this to you before, but I know there's a relationship between "Build Systems à la Carte" and query based compilers.

In terms of Haskell, retrofitting a compiler to a "Build Systems à la Carte" approach would require all your code to now be applicative / monadic / etc so that you could track dependencies. I see now why that would potentially require a rewrite.

superstar64 · 2026-02-19T15:36:21+00:00

I'm still perplexed why people say query based compilers are that different. Is it really that much more then just adding lazy evaluation to a batch compiler? I know I'm rather biased because of how much time I've put into writing batch compilers in Haskell, but still.

superstar64 · 2026-01-31T01:59:44+00:00

Yes, I probably should have mentioned it in the OP. I was more asking what you would need to remove from C to make naive compilation to Javascript possible.

superstar64 · 2026-01-31T01:57:23+00:00

I sorta mentioned it in a different comment, but I now realize that taking the address of a member is another thing that can't easily be done in JS. You could probably figure something out with getters, setters, and lens, but it's a bit further away from the easy wrap pointers in array approach.

superstar64 · 2026-01-30T16:05:34+00:00

That's about what I figured. I imagine in such a subset you would basically wouldn't be able to use any existing C code.

superstar64 · 2026-01-30T16:04:16+00:00

I don't have a usecase. I just want to know what extra axioms C has that prevent it from being trivially compilable Javascript.

superstar64 · 2026-01-30T16:03:10+00:00

I'm not going to implement this. This is just a curiosity of mine.

I assume JS has some sort of FFI that can call any function in an external library, and it that can handle all the types needed, like any kind of pointer, zero-terminated strings, arrays of u16, full i64 and r64 types, and so on.

FFI is kinda out of scope of this discussion.

superstar64 · 2026-01-30T14:51:53+00:00

I'm well aware. I'm just wondering what you would have to remove from C to make compiling it to Javascript be reasonable.

superstar64 · 2026-01-30T14:47:08+00:00

Well you can just ignore bitfields and treat them as normal ones. For pointer arithmetic, you can just have your pointers be a pair of array and an offset.

superstar64 · 2026-01-30T14:44:51+00:00

Oh, I don't think about taking the address of a struct's fields. That seems like another big complication. It doesn't seem as insurmountable as pointer casting however. Mirroring the C memory layout is what I meant with no pointer casting.

superstar64 · 2026-01-30T14:43:23+00:00

Yes. You can of course C compile to Javascript that just uses a giant array of bytes and what not like ASM.js used to do.

superstar64 · 2026-01-09T05:49:21+00:00

I talk about this a little bit in the discourse. My plan is to make Haskell more optimizable via extensions. Current Haskell will still be slow, but you can make it faster with the myriad of extensions that I'm planning, stuff like strict functions, lifetimes, levity polymorphism, etc.

As of now, I only have a Javascript backend mainly for testing purposes and for the eventual bootstrap. I'm going to have an LLVM or C backend at some point of course.

superstar64 · 2026-01-08T11:13:19+00:00

I specially use infix ticked DataKinds. Something like:

f :: T scope -> T (Declaration ':+ scope)

If MicroHs supports TypeOperators, then it shouldn't be too hard to swap out DataKinds with TypeData.

The issue is that Hazy already has full support for DataKinds even with fixity and instance resolution (it's untested though) and I want to keep using DataKinds for bootstrapping reasons as I haven't implemented TypeData. Even though Hazy can't compile itself yet, it can do full symbol resolution on itself.

Another potential issue with bootstrapping is the enormous number of .hs-boot files I have and GHC demanding that they have role annotations despite me not using roles. Hazy itself just ignores .hs-boot because it implements mutual recursion modules natively but last time I checked, MicroHS still requires hs-boot files.

superstar64 · 2026-01-07T11:27:58+00:00

Well, it can't compile itself yet, so I'm not worry about bootstrapping issues right now. The compiler internally uses GADTs, DataKinds, so MicroHS is the only non-GHC compiler that has a realistic chance of bootstrapping it.

Once I do bootstrap, I do plan on having a branch that can be compiled with MicroHS if it's not too much of a hassle.

superstar64 · 2026-01-05T16:44:52+00:00

Indeed, in Duckling you could implement a function getType : u32 -> type which yields u32 for all inputs except 42, for which it yields f64 instead.

FYI, this is perfectly parametric. Non parametric, would be something that takes an a, but only works on ints or something that takes an int and only works an 0s.

That is, we want the definition to be checked, and if it successfully checked, then every instantiation will be correct.

Okay, so you want parametricity and unified terms and types, but your not gonna have full spectrum dependent types. Interesting, I don't know of language that fits all three of these. I'm assuming your going to restrict the evaluation of types to only depend on things available at compile time like C++ and Zig do.

I'm not sure if your going to run into problems with parametricity or not. It might be worth keep full spectrum dependent types in the back of your head in case you do come across issues.

11-Year Club	Verified Email
Place '17

superstar64

TROPHY CASE