Congrats on the progress thus far! I love aspirational languages, so please keep going.
That being said, as someone who struggles with maintaining large amounts of context when I’m debugging, I’d find context-specific execution hard to follow and debug. As a concrete example, the switch to an Admin context could appear far away from the call to GetPermissions without any obvious way to figure that out. Contexts end up being a sort of global state.
If you continue with this route, it would be nice if there was a way to print out the stack of the current contexts in play and where they were set in the code.
You're correct if Context is hidden or implicit (like Dependency Injection containers or ThreadLocals in Java), it becomes debugging nightmare.
To solve this, SFX treats the Context Stack as Explicit Data, not hidden magic.
1. Debugging: Because the runtime knows exactly what 'Reality' is active, we can print it. We are building a `Context.Trace()` tool that outputs something like:
`[Base Reality] -> [HolidaySale] -> [AdminMode]`
This tells you exactly why a method is behaving the way it is.
2. Layering: Yes, contexts are strictly layered (LIFO stack). If you activate `Situation A` then `Situation B`, the runtime checks `B` first, then `A`, then the Object itself. This allows for 'Behavioral Inheritance'—you can compose behaviors (e.g., `LoggingMode` + `SafeMode`) dynamically.
3. Scoping: Right now it is imperative (`Switch on/off`), but because SFX is indentation-based, we are working on block-scoped contexts for the next release:
Using AdminMode:
User.Delete() # Admin context
# Automatically reverts here
Congratulations on having a working language. You put a lot more effort into documentation than I have, but my language is just for me. (https://github.com/dunhamsteve/newt)
You might be interested in checking out Advent of Code (https://adventofcode.com/) to exercise your language. I had fun doing that with mine.
Also, there is a programming language development discord if that's your thing and you want to discuss your project with like-minded folks: https://discord.com/invite/4Kjt3ZE
> No tooling (LSP, debugger, etc.)
If you don't want to do a full LSP yet, you can get far with simple highlighting and scraping the output of the compiler for errors. I'm also dumping some additional information (top level names / types) as json to facilitate completion and type on hover.
> Is context-oriented programming solving a real problem or creating busywork?
Not sure. This kind of reminds me of dynamic scoping, something that seems to come up in languages that don't support. Go pushes contexts through as additional arguments, and Java thread local variables cover cases that look like dynamic scoping to me.
> Should I focus on making it fast OR making the stdlib useful?
I would go with whatever sounds fun and interesting to you. You'll probably want examples of what you want to make faster if you go with the former.
> Is 1-based indexing a dealbreaker for you?
Not a huge deal, but that was surprising to me in Lua. I adapted to it, but it did cause a little bit of awkwardness in some code I wrote that decoded a binary file format (realm database).
> Would arbitrary precision by default bother you for a general-purpose language?
I only glanced at it, but it looks like the user can choose IEEE if they want. It's nice to have options and few languages have this option.
Thanks — really appreciate you taking a look and sharing links.
Advent of Code is a great idea. I’ll try a few puzzles with SFX to exercise the stdlib and find awkward edges in the language and runtime.
Good call on the tooling approach. Emitting JSON for top-level names/types and scraping compiler errors sounds like a pragmatic first step before doing a full LSP. I’ll probably add that to the build output so editors can consume it easily.
I hadn’t thought to compare Situations to dynamic scoping/thread-locals that way — that’s a useful lens. My goal is to keep the behavior explicit enough that it doesn’t become mysterious, but your point about clarity is well taken; I’ll document the trade-offs more clearly.
1-based indexing has been a little surprising for folks (Lua vibes), and it does make some low-level tasks awkward. I’m keeping it because it simplifies some semantics, but I’ll watch for real usability problems and document where it trips people up.
About numbers — yes, FastNumber is available when you need IEEE performance. I want predictable defaults but not to lock users into one numeric model.
Thanks again for the pointers and the Discord link — I’ll check it out.
Congrats on the progress thus far! I love aspirational languages, so please keep going.
That being said, as someone who struggles with maintaining large amounts of context when I’m debugging, I’d find context-specific execution hard to follow and debug. As a concrete example, the switch to an Admin context could appear far away from the call to GetPermissions without any obvious way to figure that out. Contexts end up being a sort of global state.
If you continue with this route, it would be nice if there was a way to print out the stack of the current contexts in play and where they were set in the code.
Are contexts scoped at all? Can they be layered?
You're correct if Context is hidden or implicit (like Dependency Injection containers or ThreadLocals in Java), it becomes debugging nightmare.
To solve this, SFX treats the Context Stack as Explicit Data, not hidden magic.
1. Debugging: Because the runtime knows exactly what 'Reality' is active, we can print it. We are building a `Context.Trace()` tool that outputs something like: `[Base Reality] -> [HolidaySale] -> [AdminMode]` This tells you exactly why a method is behaving the way it is.
2. Layering: Yes, contexts are strictly layered (LIFO stack). If you activate `Situation A` then `Situation B`, the runtime checks `B` first, then `A`, then the Object itself. This allows for 'Behavioral Inheritance'—you can compose behaviors (e.g., `LoggingMode` + `SafeMode`) dynamically.
3. Scoping: Right now it is imperative (`Switch on/off`), but because SFX is indentation-based, we are working on block-scoped contexts for the next release:
Thanks for the encouragement.Congratulations on having a working language. You put a lot more effort into documentation than I have, but my language is just for me. (https://github.com/dunhamsteve/newt)
You might be interested in checking out Advent of Code (https://adventofcode.com/) to exercise your language. I had fun doing that with mine.
Also, there is a programming language development discord if that's your thing and you want to discuss your project with like-minded folks: https://discord.com/invite/4Kjt3ZE
> No tooling (LSP, debugger, etc.)
If you don't want to do a full LSP yet, you can get far with simple highlighting and scraping the output of the compiler for errors. I'm also dumping some additional information (top level names / types) as json to facilitate completion and type on hover.
> Is context-oriented programming solving a real problem or creating busywork?
Not sure. This kind of reminds me of dynamic scoping, something that seems to come up in languages that don't support. Go pushes contexts through as additional arguments, and Java thread local variables cover cases that look like dynamic scoping to me.
> Should I focus on making it fast OR making the stdlib useful?
I would go with whatever sounds fun and interesting to you. You'll probably want examples of what you want to make faster if you go with the former.
> Is 1-based indexing a dealbreaker for you?
Not a huge deal, but that was surprising to me in Lua. I adapted to it, but it did cause a little bit of awkwardness in some code I wrote that decoded a binary file format (realm database).
> Would arbitrary precision by default bother you for a general-purpose language?
I only glanced at it, but it looks like the user can choose IEEE if they want. It's nice to have options and few languages have this option.
Thanks — really appreciate you taking a look and sharing links.
Advent of Code is a great idea. I’ll try a few puzzles with SFX to exercise the stdlib and find awkward edges in the language and runtime.
Good call on the tooling approach. Emitting JSON for top-level names/types and scraping compiler errors sounds like a pragmatic first step before doing a full LSP. I’ll probably add that to the build output so editors can consume it easily.
I hadn’t thought to compare Situations to dynamic scoping/thread-locals that way — that’s a useful lens. My goal is to keep the behavior explicit enough that it doesn’t become mysterious, but your point about clarity is well taken; I’ll document the trade-offs more clearly.
1-based indexing has been a little surprising for folks (Lua vibes), and it does make some low-level tasks awkward. I’m keeping it because it simplifies some semantics, but I’ll watch for real usability problems and document where it trips people up.
About numbers — yes, FastNumber is available when you need IEEE performance. I want predictable defaults but not to lock users into one numeric model.
Thanks again for the pointers and the Discord link — I’ll check it out.
This looks surprisingly fleshed out. Well done!
this is pointless, stop wasting time.
just kidding of course, don't get discouraged by some random poster on the internet