3 ms·

There's a fork called stunt / improvise that implements hashmaps. I'd love it if the list syntax was changed to use square brackets, and then if the hashmap syn

by fzzzy 3y ago

There's a fork called stunt / improvise that implements hashmaps. I'd love it if the list syntax was changed to use square brackets, and then if the hashmap syntax could be curly braces. I've also wanted to give each object an isolated environment (make each one an actor), but I haven't thought too deeply about how exactly that would work and look. I've been planning in the back of my head to do this at some point in the next year, and was planning on implementing on top of the original codebase, but if there's a rust version, I'll use that. I know it wouldn't be compatible with existing cores, but I'd be using it as the backend for a graphical ui anyway. How did you go about converting the code? Did you just read through it, or did you start with a c to rust tool? I always thought the programmers manual and codebase were quite concise and readable. One last thing, there were patches in the 90s to add journaling on top of the checkpoint system... Did those ever get merged into the main codebase? Thanks for doing this! I'm excited!

fzzzy 3y ago
I see after reading more that it has a modern concurrency and object database implementation. Really cool! Websockets and utf8 as well. Lovely.
cmrdporcupine 3y ago
"How did you go about converting the code?" Mixture of approaches. No automatic translation. After bringing over the AST and opcodes, etc most of it I wrote without reference to the original code, with the functionality in mind. Where MOO was doing something a bit funky, I often wrote code with a second window open to look at how they were doing it. But in general it came down to running a core over and over again and finding how it broke. MOO has some unexpected behaviours in spots that grew over time. If I were to start over with this, I'd invest the energy in ripping out parts of MOO and turning them into a library and then write tests that run them side by side through the same opcode sequence and compare output. But MOO was built quite monolithic, so that's hard. Re: maps, MOO's value types are immutable/copy-on-write. So while I want a map type, a typical HashMap may not make a lot of sense, as it would be doing a deep copy on each addition. Some kind of functional persistent map would probably be appropriate. Syntactical sugar for maps would be nice, and I will probably add it later. But I'm also not as concerned with the MOO language itself, as I see it as only one language among potentially many to run on the system. "I've also wanted to give each object an isolated environment (make each one an actor)" Maybe related; I intend on reworking the object reference system such that object numbers and $sysobj-references are a form of published capabilities. That is, I will be introducing "private" objects with some sort of signing & publishing & capability style references, and slowly deprecating object numbers. But that's all post 1.0 stuff.
- fzzzy 3y ago
  Thanks. Extremely awesome.

by fzzzy 3y ago

fzzzy 3y ago

I see after reading more that it has a modern concurrency and object database implementation. Really cool! Websockets and utf8 as well. Lovely.

cmrdporcupine 3y ago

"How did you go about converting the code?" Mixture of approaches. No automatic translation. After bringing over the AST and opcodes, etc most of it I wrote without reference to the original code, with the functionality in mind. Where MOO was doing something a bit funky, I often wrote code with a second window open to look at how they were doing it. But in general it came down to running a core over and over again and finding how it broke. MOO has some unexpected behaviours in spots that grew over time. If I were to start over with this, I'd invest the energy in ripping out parts of MOO and turning them into a library and then write tests that run them side by side through the same opcode sequence and compare output. But MOO was built quite monolithic, so that's hard. Re: maps, MOO's value types are immutable/copy-on-write. So while I want a map type, a typical HashMap may not make a lot of sense, as it would be doing a deep copy on each addition. Some kind of functional persistent map would probably be appropriate. Syntactical sugar for maps would be nice, and I will probably add it later. But I'm also not as concerned with the MOO language itself, as I see it as only one language among potentially many to run on the system. "I've also wanted to give each object an isolated environment (make each one an actor)" Maybe related; I intend on reworking the object reference system such that object numbers and $sysobj-references are a form of published capabilities. That is, I will be introducing "private" objects with some sort of signing & publishing & capability style references, and slowly deprecating object numbers. But that's all post 1.0 stuff.

fzzzy 3y ago
Thanks. Extremely awesome.