Toy VS ghc-proposals

Over the last couple months or so, I've totally lost my creative spark. I'd been working on a web game and a programming language for 3.5 years and 1 year, respectfully, but both of them reached a point where I don't know what to do next...

Context: I've made my own programming language (Toy), and I'm currently working on a game + engine to go with it. Having some experience with npm, I realize that it might be possible to make something similar to download Toy scripts directly into a mods folder in the game.

Funnily enough, I'm working on a custom scripting language implemented in C. Given how slow Python is, I couldn't implement my lang in it.

People need to promote their langs more - get them out there, you know? Usage is the only way they'll survive.

So I've made my own scripting language called Toy. It was built primarily in a WSL environment, using GCC - the problem is, I also want to support MSVC out of the box. I think it works pretty well as is, with a Visual Studio project provided alongside some makefiles.

And then I wrote the exact same code in JavaScript and C, and compared them. The result was quite good, IMO -

C/C++ is crunchy in a good way, Java is like chewing concrete. JavaScript used to be soft and smooth, but after making my own programming language (which felt silky smooth), JavaScript now feels too soft and sticky.

I'm making a programming language called Toy, which is intended to allow easy modding of video game logic by the players. To this end, each value within Toy, be it a number, a string, a variable name, etc. is stored in a structure called "Toy_Literal".

Don't forget the semicolon.

The goal was partially to make a good jam game, and also to test my custom scripting language Toy. Unfortunately, a combination of a new, crappier computer and the fact that it's an untested lang and engine means that it's really friggin' slow - I'm struggling to get 60fps, even when the simulation rate was adjusted.

> I think Haskell needs a way to graduate (or retire) language extensions

https://github.com/ghc-proposals/ghc-proposals/pull/601

Additionally, while this proposal is focused on the simple implementation and so in the current proposal or patterns do not bind any variables as per #522, if we do get settled on syntax and then later wish to expand to allow binding variables as in #43, then the syntax is again clean and discoverable.

Yeah, a relatively natural thing would be to be able to opt-in to having the HasField instances be available in all contexts. The (not yet implemented, but accepted) "Modifiers" GHC proposal might be nice for that.

The local modules proposal imo is excellent as-is.

Why would you drop TypeFamilies? It seems fairly popular, given that it was just one vote short of getting added to GHC2021. Do you consider it a less-ideal compromise, that is subsumed by your second proposal (Core with GRTT)?

as syntax is contentious a topic as ever, David (the main proposal author) and I would like to invite you to give your input on https://github.com/ghc-proposals/ghc-proposals/pull/585, where we propose to change the syntax of the accepted proposal #522 introducing Or patterns. In particular, we'd like to know

This looks great, congratulations on completing it! I assume you didn’t get an opportunity to evaluate the delimited continuations based eff library? It would’ve been nice to see Cont included as one of the effects covered, though perhaps not available in all the systems you looked at? Maybe some future work.

I do hope qualified exports are available someday: https://github.com/ghc-proposals/ghc-proposals/pull/283

Right. Being able to disable "custom type warnings" at use sites was part of an earlier proposal (https://github.com/ghc-proposals/ghc-proposals/pull/454) but it ended up being shelved.