The way you're using it sounds a lot like `defvar` in Common Lisp. I've never used this technique, but it sounds useful for experimental programming like modifying a server, modifying an editor, modifying a music loop (live coding) without undergoing Arc's long load times each time. ;)

Any language with user-defined macros is gonna have some trouble with its compile time or load time, since it's positively designed to run arbitrarily slow user-defined code at that time. So as long as macros at all are part of a 100-year language, then some way to reload pieces of code without undergoing the process of loading all the rest of this code must play a certain part as well. So `defvar` style can be handy, but in a more pure language we might look to incremental computation research or something.

In the longer term, how do you figure it'd be good for Anarki control whether something gets overwritten or not? Seems to me like in a perfect world, you'd sometimes want to interpret the same definition as an overwriting definition or a non-overwriting definition without changing its syntax or anything. :-p 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.

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)
     bar* (table)
     ...)

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.

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.

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.

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.

I think two changes would be better for modularity than changing assignment, however:

First, limit the ability of macros to overwrite existing symbols to the file in which the macro is called. This would allow modular or imported code to use macros without worrying about global namespace collisions, or needing to do anything special with assignments.

Second, and related to the first, would be to implicitly namespace based on file location. Currently, Arc uses a single namespace, and a reference to a root directory that's used to disambiguate relative paths called with (require).

We would ignore the root folder and use the remaining path and file name as the namespace.

This would allow explicitly resolving possible namespace collisions by referring to the namespace where necessary, the way it's done in other languages (at least in C++.) So if you had, say, a macro in news.arc with body as a parameter, first, it wouldn't mutate body in html.arc, and you could refer to (html!body) directly to disambiguate, using the same syntax for namespaces as tables.

An added benefit would be that imported code from a repo (adding a vendor path) would work as is namespaced as vendor/file or vendor/app/file.

It wouldn't be necessary to declare namespaces in most cases then. We could use the existing with statement to declare or extend namespaces instead of something like (declare-sub-namespace), similar to 'using' in C++

    (w/namespace foo
      (= bar (table))

    (foo!bar)

once-only: execute arbitrary code but only the first time it's encountered. https://github.com/akkartik/readwarp/blob/master/utils.arc#1

init: like assign, but only if name isn't already bound. For arbitrary variables besides tables. https://github.com/akkartik/readwarp/blob/master/utils.arc#L...