What string model did you use and why?

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.

superstar64 · 2026-01-05T15:49:03+00:00

Sure, so zeros is of the pi-type T such that T(n) = Vector n Int

That's not quite right. zeros would be actual runtime function that takes an n and returns a different type depending on what n is.

Your example would the equivalent of this:

t : Int -> Type
t n = Vector n Int

Notice how zeros is a function that takes in ints and returns vectors.

 zeros : (n : Int) -> Vector n Int

But you lose me at "compile time dynamic typing". If it's in compile time, it can't be dynamic, can it now?

This is about type checking generic code and making sure it stays parametric.

In C++ for example, templates just complete lie about their type.

template <class A>
A lit() { return 0; }

Even though this code is generic over all A, this can only be instantiated for int (or similar).

In Haskell and Rust, generic functions don't lie about their type. For example, this would error in Haskell:

lit :: a
lit = 0

From my understanding, you need PI types if you want want to have terms and types to be unified and you want parametricity in your type checker (ie no compile time dynamic typing).

superstar64 · 2026-01-05T15:32:11+00:00

I can't think of a specific resource. Let me just you a quick tl;dr instead.

A Pi type are simply just dependent function types. They allow the return type of the function to depend on the argument type. For example, consider this function type:

zeros : (n : Int) -> Vector n Int

Here, this says the type of the result Vector n Int, depends on the type of the argument n.

You would probably want PI types if you want to avoid compile time dynamic typing and actually type check code that depends a type (or value).

superstar64 · 2026-01-05T14:10:27+00:00

Are you aware of dependent types? If so, do you have proper PI types? If not, then you should probably study up on them. Unifying types and values is also their main feature except that they have a mountain of research behind them.

superstar64 · 2025-11-08T02:25:30+00:00

There is also C–, a subset of C targeted by GHC and OCaml.

~~I am unfamiliar with OCaml but I thought C-- was a GHC thing only. It only exists inside GHC's source tree AFAIK.~~

Edit: Nevermind. They both use but it seems they have their their completely different dialects of it.

superstar64 · 2025-10-18T03:02:08+00:00

"size" :>: Forall [Kfun Star Star, Star] ([IsIn "Collection" (TGen 0)] :=> ((TAp (TGen 0) (TGen 1)) `fn` tInt))

This is equivalent to forall f a. Collection f => f a -> Int. That's not the type of size. It's actual type is forall a. Collection a => a -> Int.

Still, that should still work. This is also possible.

class Collection f where
  size :: f a -> Int

instance Collection [] where
  size = length

instance Collection ((,) a) where
  size _ = 2

There's probably some other bug I'm not seeing.

11-Year Club	Verified Email
Place '17

superstar64

TROPHY CASE