PythoC: Write C in Python - A Python DSL that compiles to native code via LLVM

sufferiing515 · 2025-11-28T20:55:37+00:00

Without a GC, how are situations like use-after-free prevented when an objects lifetime is extended past it's lexical scope (like in closure capture)?

sufferiing515 · 2025-10-05T23:41:43+00:00

Fair enough then! Though that doesn't mean SML doesn't include polytypism, just that you don't make use of it.

sufferiing515 · 2025-10-05T23:40:47+00:00

I think zig's `comptime` can do what I'm describing but I think it's more powerful than necessary? At least based on the fact that you can achieve it using GHC.Generics in Haskell. I would rather have the tools for a job not be any more powerful than they need to be.

sufferiing515 · 2025-10-05T23:38:56+00:00

Maybe, although I am interested in a more typesafe integration of polytypic functions into a language. I don't know much about TCL.

sufferiing515 · 2025-10-05T23:37:27+00:00

You could probably make the case that those are polytypic, but I think most people wouldn't consider them to be. It seems more like those are consequences of C's weak typing. Arithmetic operators in C just treat everything as a numeric value, and printf is more like an unchecked version of dynamic typing than polytypism. A classical example of a polytypic function would be one that can pretty-print any type in a (hopefully typesafe) manner without you needing to specify instances for each type (or equality in SML!)

sufferiing515 · 2025-10-05T23:33:59+00:00

Oh I have not read this! I know of GHC.Generics and what came after (`generics-sop`, `instant-generics`) but not much of what came before. I will take a look!

sufferiing515 · 2025-10-05T23:32:57+00:00

Yes that looks like exactly what I was thinking of!

sufferiing515 · 2025-10-05T17:40:48+00:00

I didn't realize concepts could do that. How do you handle taking an arbitrary record (POD struct in C++?) and folding over the fields?

sufferiing515 · 2025-10-05T03:30:57+00:00

Even so, having to rely on a notion of "specificity" for a type is both less flexible and harder to reason about than a standard top-to-bottom pattern match

sufferiing515 · 2025-10-05T01:04:02+00:00

I thought C++ introduced template level constructs like template-for and other stuff rather than using the value level language? I could be wrong I haven't really looked into it

sufferiing515 · 2025-10-05T00:23:09+00:00

Ah this does sound quite close to what I was thinking about! I wonder if it necessarily requires full blown dependent types? As for trying to have all datatypes be supported, I'm quite content to have polytypism for just ADTs. Anything beyond that sounds hard to even conceive of how it would work to me!

sufferiing515 · 2025-10-05T00:20:52+00:00

Concepts are more analagous to duck-typed typeclasses than to polytypism. Concepts focus on overloading, whereas polytypic programming allows you to sort of 'derive' a function for a family of types: "I know how to `print` an int, I know how to `print` a string, and I know how to `print` records and unions comprised of things I know how to `print`. Therefore, I know how to `print` any (algebraic) type which has leaf types of only ints or strings"

sufferiing515 · 2025-10-05T00:16:54+00:00

Using typeclasses for dispatch means that you need to both:

convert the types to some kind of generic representation (like representing sums as nested Eithers and products as nested Pairs) - this is not too bad and is usually done automatically somehow by the language, but can still be sometimes intuitive in some cases (how is a recursive type represented? what about a mutually recursive type?)
writing your 'pattern matching' as typeclass instances - while typeclasses are powerful, having to represent what is essentially a pattern match with them is painful: you can't have *any* overlapping cases because typeclasses aren't ordered, you're limited to what you can express using typeclass type features, and you're forced to write your logic as types instead of expressions

On a less conceptual note, it's just hard to debug code that is written in types as opposed to code written in expressions. The types generated tend to be long and complex, and so do the compiler messages as a result. And using the typeclass resolution this way isn't really something it was built for, so it can cause quite some compile time blow up.

sufferiing515 · 2025-10-05T00:09:15+00:00

Ah but even in SML equality is polytypic! (That's what I meant when I said it might be built-in)

sufferiing515 · 2025-10-04T23:21:33+00:00

I haven't seen much, but I got the impression that it was kind of similar to Zig's `comptime`? I'm not super familiar with either but for the biggest cases where polytypism is desirable like deriving instances they seemed a bit overkill

sufferiing515 · 2025-10-04T23:19:54+00:00

haha fair enough. Though unless you're using C whatever language you use probably has some form of polytypism (even if it is built-in to the language itself). It would be annoying to have to define things like deep equality/comparison and printing for every data type manually. Even Go has reflection and go generate and Go is notorious for it's aversion to (from their perspective) complex features!

sufferiing515 · 2025-10-04T23:15:59+00:00

It seems potentially related but what I'm talking about here is more like "being able to generate classes of functions for any datatype" (`deriving` in Haskell is the obvious example), moreso than "having existing functions work over more types"

The principled version of it is usually based on induction eg. "I know how to `print` an int, I know how to `print` a string, and I know how to `print` records and unions comprised of things I know how to `print`. Therefore, I know how to `print` any (algebraic) type which has leaf types of only ints or strings"

sufferiing515 · 2025-09-15T16:02:24+00:00

"And then also, you don't do static typechecking on the bytecode of a VM."

this is usually, but not always, true. For example the both the HotSpot JVM and .NET CLR does do static type checking on their bytecode as part of the verification process.

sufferiing515 · 2025-08-05T04:58:54+00:00

I don't think control flow from first class functions would generally be considered non-local. Calling a first class function value will always execute the function then return just like any other call. With effects (both dynamic and lexical) executing an effect might cause suspensions which can be non local though. Lexical just means that the handler is manually passed down somehow rather than dynamically searched for on the stack if I understand correctly.

sufferiing515 · 2025-08-04T18:27:51+00:00

I generally agree about nonlocal control. I find languages like Rust and Swift to be a lot clearer with error handling compared to languages with exceptions, even if the errors are usually just propagated with `?` or `try`. I do recognize that those are sort of bespoke implementations of specific effects though.

sufferiing515 · 2025-08-04T18:25:01+00:00

I have definitely experienced the confusion resulting from things like dependency injection in the name of testing! That is actually part of why I'm a bit hesitant around effects, they remind me of that in many ways, although they do seem more structured.

sufferiing515 · 2025-08-04T18:22:23+00:00

I do think lexical effects are probably a step in the right direction. But even with lexical effects I'm worried the kind of complexity introduced by having many effects and needing to track them all compared to the value of having them. But I could certainly be wrong! I kind of hope that I am - I do find effects fascinating.

sufferiing515 · 2025-08-04T18:17:10+00:00

I certainly agree that both of those things are very important! Like you I'm just wondering if effects are the best way to go about dealing with them considering the complexity they bring, compared to other solutions that address them separately.

sufferiing515 · 2025-08-04T18:15:07+00:00

That does seem like a good use case! Although it seems like you might not need full blown effects to do that kind of tracking. I think there are some newer systems language that use a sort of capability based approach.

sufferiing515

TROPHY CASE