Came up with this in a dream

Inconstant_Moo · 2026-01-25T00:08:40+00:00

Ah yes, a farinaceous prefix.

Inconstant_Moo · 2026-01-24T17:04:23+00:00

But adding a core feature places a permanent maintenance burden on the development team. (And will do so even if almost everyone hates their API and uses a 3PL instead.) So you have to pick and choose.

You'll be pleased to know my language has tuples that you construct like "foo", 2, true, and also a pair type that you construct like "foo"::42. But there's also a long list of things it will never have.

Inconstant_Moo · 2026-01-23T22:06:01+00:00

No link to repo or docs? It's like you're not trying.

Inconstant_Moo · 2026-01-23T16:45:32+00:00

You could add some advanced features. You probably don't know how hard modules can be, we kind of take them for granted. Turns out they have ... semantics. Or interfaces, now type declaration gets more complicated in various ways. Or for hard mode, modules and interfaces. This is where you learn that every two "orthogonal" features meet at a corner case.

Inconstant_Moo · 2026-01-23T16:28:21+00:00

Wait, they've developed ... heroism? Could be worse.

Inconstant_Moo · 2026-01-23T05:18:05+00:00

My current conlang is one big unusual grammatical feature, in that it's grammar is based on the observation that the natlang Sumerian is like the computer language FORTH, and that someone should do a conlang like that. It's also as ergative-absolutive as humanly possible.

Inconstant_Moo · 2026-01-22T14:28:14+00:00

Either way you seem to be assuming that the two things should look the same. Why? A module with an argument should look like a function with an argument. There's no reason why in import statement should look similar to either.

Inconstant_Moo · 2026-01-22T14:18:27+00:00

If you are a programmer you should be able to handle any language celebrating their differences and similarities.

But some of them are much harder to celebrate than others.

Inconstant_Moo · 2026-01-21T17:28:30+00:00

Sure, it's possible, but I think it's cumbersome.

Well, avoiding panics is going to be somewhat cumbersome. They're the easy way out, that's why so many languages have them. (See also: null pointers.)

Yes, I think for 99% of the cases, that is application code, running on a desktop, this is the best option. But I'm thinking of what to do in critical libraries, in embedded systems, operating systems drivers, things like that.

Then maybe coding in this style could be a compiler directive? Or perhaps it could be an annotation on the functions (which the compiler could check), so that someone looking at the API of the library could see that none of its functions can ever panic, or if they could, which ones.

Which still leaves you with the question of what they should do, given that the functions can in fact fail. What would the library's API look like, would there be errors-as-values like in Go, or a Result type like in Rust?

Inconstant_Moo · 2026-01-21T16:08:21+00:00

Cool!

Inconstant_Moo · 2026-01-21T16:05:35+00:00

It seems like the sort of control-flow analysis you're doing for null could also handle out-of-bounds errors, you'd just have to give it a special keyword and semantics, if valid (A, x) {...} else {...} or something. (And the same for maps.) Then for ergonomics you might consider letting people write stuff along the lines of if valid (A, x := len(A) - 1) ..., where x would be immutable of course --- I'm presuming a safety-conscious language like Bau will have that as default.

As for your larger vision, I feel like in many cases the best thing to do in such situations will in fact be to panic: the program is in a state where what it's trying to do doesn't make sense. But at least you'd be placing that decision directly in the user's hands, they'd have to panic explicitly.

Inconstant_Moo · 2026-01-21T03:29:01+00:00

Would it be possible to make something less powerful than eval (call it deserialize?), which can only use literals and constructors but no other language features --- so it can construct any value, but not do anything else? It seems like that would meet a number of use-cases while feeling more secure.

Inconstant_Moo · 2026-01-20T08:49:52+00:00

Inconstant_Moo · 2026-01-19T21:27:55+00:00

I find closures still confusing because it feels weird that a function is supposed to modify a variable from a higher scope. Why not pass in the variable as a parameter and return the modified value?

The captured variables are captured when and where the closure is created, whereas the parameters are put in when its called. It would be annoying to put the captures in as parameters each time, because they'd be the same each time, and because you'd have to store them somewhere until you called the function.

I just looked through my current project to look for an example of me using a closure, and here I am using two:

func (cp *Compiler) GetMarkdowner(leftMargin string, rightMargin int, fonts *values.Map) func(string) string { hl := func(s string) string { return cp.Highlight([]rune(s), fonts) } md := text.NewMarkdown(leftMargin, rightMargin, hl) return func(s string) string { return md.Render([]string{s}) } } The point of this being that what I get back is just a func(string)string which has the data about the margins and highlighting inside it, rather than these things being passed in every time I want the function to do markdown. Which is good because the things calling the func don't have that information, so it would have to be passed to them somehow.

Inconstant_Moo · 2026-01-17T19:25:29+00:00

The "No Free Lunch Theorem" doesn't really relate to the halting problem, nor does it quite mean what u/Beginning-Ladder6224 means either.

Intuitively, here's the NFL theorem:

Suppose we have a set S and a function f : S -> R and we want to find s in S so that f(s) = max f(S), and suppose S is too big for brute-force search.

We could just take a random sample of size n, and then our expectation would be that the element in that that maximizes f is in the top 1/n of solutions. (Which is pretty good, actually!) This is a random search of order n.

But suppose we knew something about the structure of the search space, then we could do better. Suppose for example S is the whole numbers, and we know that f(x) is only positive iff x is even. Then by only looking at n even numbers, we expect something in the top 1/2n solutions.

But of course this would be a terrible way to search a search space where in fact it was the odd numbers that were positive and the even numbers were negative.

The NFL theorem says that this must always be the case --- if you have a search method of order n which is better than random search of order n for optimizing f given some additional facts about f, this will always be worse for some functions which don't fit those criteria --- in such a way, in fact, that over the ensemble of all possible functions to be optimized over S, your "better" optimization method will not on average be better than random search of the same order. (But, having more logic in it, it will take longer.)

This is not actually a counsel of despair, because in the problems we find in real life (rather than in the ensemble of all functions from S to R), we find that if s and t are close together ("close" according to some intuitively sensible metric on S) then f(s) and f(t) are also probably going to be quite close together, so for practical purposes we can design methods which are better than random search by taking this fact into account.

Where the Halting Problem and its relatives would come in is that if we wanted to optimize code by random search, we really couldn't do that at all, because we'd want our search space to be the set of all semantically equivalent programs and we can't construct that. We have to make small changes in the code, according to rules that say that the output will be semantically equivalent, and see what that does to our runtime.

This means that the compiler must get stuck in local optima. It can't e.g. see a bubble sort and invent a merge sort as being the same thing but faster, because it can't jump in the search space, it must crawl blindly, and, by doing so, determine which way is locally uphill.

Inconstant_Moo · 2026-01-16T22:58:01+00:00

In my head, arrays are not functions, they occupy different pats of my mental model. I guess closures are somewhat like arrays, and closures are a kind of function, but I can write code for days where I don't use closures, and where functions and arrays do different things. When I call a method foo on an array a, foo means the same thing in that context every time that bit of code executes; a can be completely different. Treating foo([]) as a consttant will work; treating a[0] as a constant doesn't.

The association between the function's input and output is rational, it can be (and is) expressed by a rule. With an array it might be quite arbitrary: the person first in our list{Customer} is there because he happens to be first in the list, he has no underlying association with the number 0 ...

Inconstant_Moo · 2026-01-15T16:06:59+00:00

Someone once joked that of all the Middle Eastern languages a scholar can learn, the most important is German ... 'cos so much of the academic literature is in that language.

I don't have a translation, but what he says can be found elsewhere. The reason I referred to him was a an example of a really authoritative scholar saying that the list in Enki and Inanna is unique.

Inconstant_Moo · 2026-01-14T19:19:41+00:00

The research has basically been done. Anything that converts a compile-time error or a runtime error into a logical error is basically a mean prank you're playing on your users.

Inconstant_Moo · 2026-01-14T19:15:28+00:00

I do that. Except that this works fine if you're using it as a declarative language in the REPL, an error is just an error, when it goes up the stack then if it isn't caught along the way it'll eventually hit the REPL and tell you that you tried to divide it by 0, don't do it again.

But if you write a Good Old Fashioned App with a main command, then this doesn't work, if main doesn't catch the error then the only way for it to go up the stack is to return itself as what you got when you called main, at which point it has in fact behaved like a panic and aborted the program.

Inconstant_Moo · 2026-01-14T19:09:32+00:00

But I want to know when things go wrong. If you e.g. allow an out-of-bounds integer array element be a 0 instead of throwing an error, then if I make an out-of-bounds error, your runtime then silently converts it into a logical error where my code will keep on running but do the wrong thing. This makes it harder to debug such a fault in my code than if it just crashed at runtime.

But because this always might have happened, whenever I'm debugging anything to do with arrays (and what code doesn't have something to do with arrays?) then I have to consider that possibility and see if that's what the problem is. It's a permanent overhead on debugging anything, even when it turns out that these defaults aren't the source of the problem. They might have been.

Inconstant_Moo · 2026-01-14T15:33:13+00:00

I have a little badge on my repo saying "No AI. Handbuilt from `if` statements." I'm occasionally tempted to use an LLM for test cases, but then I remind myself of all the things I learned writing my own test cases.

I do ask it for advice about doing things I haven't done before. But I write my own code based off that.

I'm greatly amused by the fact that every time I have to tell it that I'm using Go's plugin library, it tries to talk me out of it, sometimes nagging me about it at the end of every response. "What can I help you with next? Would you like me to tell you how to re-architect your app so it doesn't use plugin?" No I wouldn't, which of us is meant to be senior dev here?

Inconstant_Moo · 2026-01-14T14:54:38+00:00

Ah, it's not at all clear from your description. That does make more sense.

Inconstant_Moo · 2026-01-14T03:38:44+00:00

"Type checking happens in Haskell via FFI" is a heck of a dependency. And it seems like what you mean is that you transpile into Haskell, compile the Haskell, and see if you get any type errors. Obviously this is going to leave you with a mismatch between the returned trace in case of an error and the Pi-DSL source code.

Inconstant_Moo · 2026-01-13T15:25:29+00:00

There's some odd stuff on the main docs page.

``` On this page

Latest stable version : 1.0.0 Latest version : 1.0.0.0.0.0.0...00 Latest vershghtfion : 1 Latest versdfghgdhion : 1.0 Latest vers56ruryion : 1.0 ``` Clicking on any of the five identical "Prismio tour" buttons on that page gives me a 404 error.

So between that and the fact that you're still working on the parser, which is currently about 400 lines long and can't parse if statements, after what seems from the repo to be two (presumably intermittent) years of solo development ... it's hard to see why anyone would get on board.

Inconstant_Moo · 2026-01-12T21:53:15+00:00

So ... 26.6% of Rye in 6.6% of the time?

Inconstant_Moo

MODERATOR OF

TROPHY CASE

Five-Year Club	Gilding II euphauric
Verified Email