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

Sadly the highlighting is substantially slower than expected, it takes around 2s to colour a file on my shitty little laptop. I'll see where the time is spent and try to carve it down because I know for a fact that the analysis itself takes about 20ms, but this is something the internet warned about when using text editor decorations to supplement the native grammar system that is built on regex and all around inadequate to express the flexibility of Orchid.

Not bad. What is cps and why is it everywhere? 😄

@Lensflare It's sugar for passing the rest of the body as the last argument of the following expression, wrapped in a lambda if it's a cps=. It stands for continuation-passing style. Since Orchid is a pure language, this is how you encode side effects.

@lorentz hmmm… like F#'s pipe operator? Or more like a monad?

@Lensflare The pipe operator was inspired by Elixir's identical operator, at a glance F# seems to have the same concept. It literally just makes lhs the first argument of rhs, pushing all other arguments back by one.

@Lensflare continuation-passing without the syntax sugar looks a bit like a callback chain. In contrast to a monad, this makes no statement as to what kind of effect the function might have. To type it, I'd need algebraic effects.

Edit: I screwed up the example, the return value should be std::exit_code::success, this program would hang. Plus, the imports are redundant here.

@Lensflare Ah, I see why you asked about the pipe! It's true that, like the pipe operator, cps allows you to inject an argument into a function call expression. From that perspective, the differences are:

1. cps puts the new argument at the end of the call expression

2. cps passes a lambda if you specify expected outputs with the `cps ...names = ` syntax

3. cps is a kind of statement, so it must always be a semicolon-delimited entry in a do-block. Do-blocks allow every statement kind to decide how it wants to use the continuation, so they're useful for control flow.

Cool! You implented disk io 😁

@retoor I've had disk IO for a while, it's just not very good because it's not a priority. socket IO will be better because it's a testbed for backpressure mechanisms, but neither of these are particularly high priority because as an embedded language Orchid likely uses the host application's networking system.

@lorentz don't get it. Sockets is the host application networking system right? In C, it requires some minimal changes to make it work on windows and Linux. In python there's no difference between windows / Linux with almost same api. Same counts for php. It's all stolen from C

@retoor I mean, Orchid is meant to be embedded in another application to enable scripting some behaviour. If that behaviour involves networking, the host application is expected to provide application-layer protocols and high level APIs optimized for that environment. Building an application layer protocol that actually works out in the wild with a dynamically typed immutable language is not a good idea.

@lorentz oh, totally understand now. Kinda like Lua. Have you seen the lua source? It's amazing. That's some good programming right there.

Is your language only able to embed in some rust application or also using a C(+++) api?

I implemented Lua in a c editor app (kilo editor) and it was amazing. So smooth. It's even easier to embed as python. Maybe you can look into embedding lua for ideas

I like how pretty it is.
Nonetheless, the syntax and structure seems off-putting to me personally.

I can't quite put a finger on what it reminds me of.
Maybe Lisp without the parentheses and rust and python somehow?

Specifically the "cps" here reminds me of my old Lisp stuff. Does it stand for continuation-passing-style or is it some of your own magicks?

@retoor Lua is an absolute bliss to embed, but Orchid is lazy which complicates things a lot. C is also a sort of common denominator between all languages, you have to hide the expressive parts of your program during C interop and regress to pushing numbers around.

I think it should be possible to write a translation layer that uses the common subset of Rust and C to express Orchid's concepts. Right now the exact boundaries of these concepts are very volatile so it's too early to consider such things, but eventually it's likely that a simple C ABI would emerge that makes it easy to write bindings for other languages.

The biggest barrier in my opinion is that for bindings to be any good, the translation layer between the two languages needs to be able to represent lambdas and mix both languages in the call stack.

@retoor Your question and the US government's incessant bitching about memory safety inspired me to design a message passing based API for native extensions which fill a similar role to Erlang NIFs in the standalone interpreter, orcx, instead of the originally planned ABI. This API shares almost all capabilities of the embedder API, so I'll likely expose that through stdio as well, which should make it easy to embed Orchid in just about anything.

I fucking love stabby. That being said, my API is still message-based, but if I ever wrote an API that had no consumers outside rust, I'd choose stabby in a heartbeat, and I'm already considering it as a shortcut for when the extension is trusted and written in rust, like the standard library.