I'm struggling to write a function that finds a subsequence in a sequence. I made a fucking programming language and String::find is where I get stuck. Fucking fuck.

Impostor syndrome hitting hard today

Thanks, that smiley is direly needed to cope with the bizarre language that is the ABI stable subset of Rust.

Today in Rust I defined a function that takes Any and returns Any specifically so that parametric types turned into trait objects of this trait can still receive commands without having to know their concrete type.

Bridging static and dynamic typing is one hell of an exercise.

If you can see yourself experimenting with an early alpha programming language to provide feedback and perhaps contribute, what feature would you expect from the get go? (Up)Vote in comments, add if missing

VSCode is doing really strange things to my language server, in such variety that I'm starting to suspect that it's simply incorrect because it's very unlikely that I'd misunderstand so many distinct things at once.

- The trace level is verbose, yet VSCode absolutely spams the LS with trace: off requests

- the capability update request I used to set file watchers never gets a response even though the standard clearly states that all requests must get responses or progress reports quickly, and I'm not getting file updates even after vscode responds to a file system change. By the way, if file watching is a capability, why can't I set it in the protocol handshake with all the other capabilities?

- my semantic token provider (used for syntax highlighting) is simply ignored, no requests, no errors

- the debug console is spamming editor internal errors

Orchid syntax highlighting

I gotta say, I really like the text image of my new language ^_^ This is something I was worried about, although that's part of the reason why the entire syntax is defined natively and can be modified on a whim

I literally spent a week fighting scope creep instinctively introduced by myself on a submodule with the nominal role *Read all files the compiler needs to read using the fewest possible additional steps*

I have to keep reminding myself that there's no such thing as a scope too narrow. If its purpose can be described without spelling out the implementation, it can be encapsulated.

Orchid runs!

It's very far from done, but now I'm motivated to get shit done! My optimizations can now have measurable impact! The hypothetical examples no longer have to be hypothetical!!!

My preprocessor is just generalized kerning, the macros are variations on the single well-known proof for the Turing-completeness of GK, the type system will probably be a Prolog reskin so simple the translator can be a FSM, the type inference algo is the original HM algorithm which I don't even need to change, the core language is Lambda calculus and no more, and the backend might just be Erlang itself if my research confirms that extending LLVM until it consistently beats Erlang is unrealistic.

I invented nothing, I create nothing. All I do is plug circles into square holes and fill the gaps with play dough.

Okay, my initial revulsion for ABI has receded. All things considered, my options aren't that bad. I just had to change my perspective from "huge downgrade from static linkage" to "huge upgrade from a message channel".

Just like a web API, I have to draw a continuous line through the program that separates specific concerns of interest that must fall on one side or another, and which can only cross through things with specific properties.

There are several crates shipping a number of different binary-compatible types, even generic types. Not everything can cross, sure, but maybe not everything should cross either. Maybe a DLL should receive an opaque handle for certain things, such as interpreter internal code representations. Maybe having these separated is important enough to justify having a translation layer.

I'm sure there's much woe ahead, but I'm learning to stop worrying and love the ABI.

I just had to drill an error reporter through the entire Orchid codebase for multiple fatal error reporting. The caller constructs a reporter and passes it into the interpreter, various internal interpreter functions put errors into it and return meaningless but valid substitute values, then the caller checks the reporter for recorded errors and avoids using the return value if there were any.

I have recreated ERRNO in a high level language.

I think I understand now why people dislike continuation passing style for side effects. The continuations passed to the action can be called in any pattern, there's no inherent guarantee that an error handler cannot be called just because the corresponding success handler had already been called. In this regard they act like jump points in assembly more than functions in an equation.

I don't think this is such a massive problem. The entire imperative world is built on such things. I definitely think though that this model does not mix with autocurry.

ISO floating point numbers are essentially wrapped in a hardware-level monad because the normal meaningful values aren't closed over basic arithmetic so conceptually wrapping everything in Maybe using the 'infectious sentinel value' NaN leads to substantial speedups.

With this in mind, I think high-level languages that have a Maybe should use those and have the language-type float refer to a floating point that isn't NaN.

It baffles me that although all they're doing is shuffling numbers around based on abstract descriptions of the target architecture and platform-specific behavior is completely out of the question, compilers are some of the least portable programs in active development.

I was really teasing myself about it a week ago, but I definitely think now that building a language server before I try to get people to try Orchid is the right call.

There is a ceiling to the quality of error reporting without editor support, and because I'm not happy with the best I could've possibly gotten, I didn't really put that much effort into it. Before I got started on the language server, the interpreter would fail with the first error.

Because with LSP the new theoretical limit of DX is the lack of type information which still isn't great but it's a problem I already live with, I'm compelled to meet that limit by perfecting error detection.

It also helps that the interpreter's startup time is 2ms so I can simply run it in thread on every keystroke to generate truly live, basically instantaneous feedback.

Some more Orchid progress. Dynamic dispatch, pattern matching and template strings:

I need to finish something presentable by May so I decided to make Orchid an untyped language, and the simplicity of all tasks all of a sudden breaks my heart. Static analysis is my guiding principle, the one feature which I always held to be good. Deprioritizing it in _my own programming language_ feels like sacrilege.

Adding opportunistic move to a large recursive tree processor is not a fun exercise, I would advise anyone who intends to dabble in interpreters to design with opportunistic move from the get go.

Yet another unusual take for the Orchid STL: Unicode codepoints aren't a part of the string library.

For the purposes of a high level language, the unit of text is a grapheme. Strings can be converted between Unicode and binary blobs. In a binary, indices address bytes. In text, indices address graphemes. For example, searching a string for a substring that consists of a single letter implies the added constraint that the letter must not have accents or other modifiers.

For storage and transfer optimization it's possible to discover the byte length of a string without converting it to binary

The number of concurrent transformations impacting more than half of the codebase in Orchid surpassed 4, so instead of walking the reference graph for each of these I'm updating the whole codebase, from lexer to runtime, in a single pass.

In this process, I also got to reread a lot of code from a year ago. This is the project I learned Rust with. It's incredible, not just how much better I've gotten at this language, but also how much better I've gotten at structuring code on general.

Interestingly though my problem-solving ability seems to be the same. I can tell this by looking at the utilities I made to solve specific well-defined abstract problems. I may have superficial issues with how the code is spelled out in text, but the logic itself is as good as anything I could come up with today.

A register machine with strings and hashmaps as the only data types and no stack. You have to make one from a linked list of hashmaps.

The tokenization of Orchid files depends on the exports of imported files, but in a way that never influences their exports or imports, so Orchid allows circular references.

I sometimes feel like my subconscious and conscious mind use the scope of my projects to annoy each other.

Orchid lesson #many:
Church tuples exist only to demonstrate how general substitution is. Just like Church numerals, they aren't meant to be used for real computation and cause a lot of problems. Few type systems and fewer optimizers can deal with them, they're a pain to pass through FFI boundaries, and they're much slower in an interpreted context than a native smart array. And in a lazy language the tuple is almost always lighter than the code that generates it, so you want to generate the tuple eagerly and thunk the actual elements, if thunk you must.

I'll go write a vector based tuple and end this madness tomorrow. New version soon, probably.

With dynamic dispatch.

Hot take: Rust doesn't go far enough with explicit clone; dropping any type that isn't trivially copiable should also be explicit. I don't mean that it should be leaked if you don't delete it, I mean that the compiler should force you to explicitly say

"I am done with this object, anything that had to know about it has already been notified and either there isn't a single last point of use or it isn't a clone, therefore dropping is justified."

This is the whole meaning of dropping a complex object. I think that this is far too strong a statement to imply in bulk for every value in scope at the end of the function.

I'm working on an internal overhaul for Orchid phasing out the last bits of code from May's crunch and making the loading pipeline much more transparent and easier to optimize, but I'm starting to get really tired of high theory and tree walking algorithms.

What are some light hearted projects that can benefit from a scripting language? I don't mind if existing scripting languages would be an objectively better choice, I don't want to build something perfect here, I just wanna have fun with this project again.

What's the message passing IPC with the least RTT for messages that are in the 16-32 byte range? It's gonna run approximately once per command in an interpreter.

What's your idea of a perfect number?
Mine is:

default decimal, prefix for binary, octal, hex

Integers in natural notation with strictly positive exponent

All bases allow natural notation, where the exponent is always a decimal number and represents the power of the base (0b101e3 = 0b101000)

Floats in all bases allow a combination of natural notation and dot notation

Underscores allowed anywhere except the beginning and end for easier reading