In the longer term, how do you figure it'd be good for Anarki control whether something gets overwritten or not?
Definitely leave it up to the user.
Some variables (like constants) should always be overwritten, and so the user should write `(= foo* 42)` for those.
Other variables (like tables containing state) should only be set once on startup.
Like, maybe we'd eventually want a `load-force` operation that loads a file in an "overwriting way." At that time, if we simply have `load-force` interpret all `or=` as `=`, then it might clobber too many uses of `or=`, so my advice to use `or=` for this will have turned out to be regrettable.
Perhaps, though FWIW I haven't needed a force-reload type operation. That's accomplished via restarting the server.
The only drawback for `or=` is that if you have code like this:
(= foo* (table)
then you'd have to reindent the whole expression if you change from `=` to `or=`.
That's not a big deal though. I think I prefer `or=`.
Thanks for answering. That makes the intentions pretty clear. :)
Another thing... Have you considered initializing the application state in one file and the hardcoded constants and functions in another, so that when you're changing the code, you can reload the constants file without the state file getting involved at all?
Sure, but losing data you don't want to lose because you reloaded a source code file does seem like more of an architectural than language issue. It would be a code smell in any other language.
My comment was slightly facetious but the more I think about it the more I'm wondering whether something like redis or php's apc wouldn't be a good idea - and not just as a lib file but integrated into Racket's processes for dealing with arc data directly.
It could serve both as a global data store and a basis for namespacing code in the future (see my other rambling comment about namespaces), since a "namespace" could just be a table key internally.
Languages that have decent bindings to a database also have global variables that still have uses, and that can be lost when you restart the server or do other sorts of loading manipulations. There's a category of state that you want coupled to the state of the codebase.
Yes, you can definitely try to make these different categories of state less error-prone by architectural changes. But I don't think other languages do this well either. Mainstream languages, at least. I know there's research on transparent persistence where every global mutation is automatically persisted, and that's interesting. But I'm not aware of obvious and mature tooling ideas here that one can just bolt on to Arc.
All that said, database bindings would certainly be useful to bolt on to Arc.
Otherwise hitching the code to a third-party db, as a requirement, would really limit what could be done with the language and would create all kinds of problems. You would be locked into the db platform as a hardened limitation. You would inherit the complexity of external forces (i.e. what if some other app deletes or messes with the db). What about securing the access/ports on the db.. etc..
It's always possible, but I think you would have to implement something internal where you can properly isolate and fully support all platforms the language does.
Seems likes namespaces would solve these problems the right way.
Yes. Currently, the options we have for stateful data are file I/O, which doesn't work perfectly, or tables that can lose their state if the file they're in gets reloaded. I'm suggesting something like Redis or APC, but implemented in Arc at the language level, to separate that state from the source code.
I was also thinking (in vague, "sketch on the back of a coffee-stained napkin" detail) that it could also be used to flag variables for mutability and for namespacing. In that if you added "x" from foo.arc it would automatically be namespaced by filename and accessible elsewhere as "foo!x",so it wouldn't conflict with "x" in bar.arc.
>Otherwise hitching the code to a third-party db, as a requirement, would really limit what could be done with the language and would create all kinds of problems.
Yeah, but to be fair, Arc is already hitched to Racket, which appears to support SQL and SQLite, so maybe third party wrappers for that wouldn't be a bad idea as well... sometime in the future when things are organized enough that we can have a robust third party ecosystem.