is somehow difficult to read? (arguable, this is an arctable and not a dictionary which is closer to an associated-list. If it were an associated-list you'd be able to do it as either:
(if (assoc "username" arc-alist) ... )
or
(if (alref arc-alist "username") ... )
I'd hardly call any of these difficult to understand; though perhaps assoc would make more sense if the list were the first parameter and the key the second like the alref works. i.e.
(assoc list key)
rather than:
(assoc key list)
Because at the minute alref and assoc are not conforming to the same standards, which make them rather awkward to use.
True, but the returns are more useful (assuming has_key returns T if it has the key. I am unfamiliar with python I'm afraid).
If the current syntax is difficult to memorize, you could always write a simple function which abstracts it away into something you're more familiar with:
In JavaScript they're the same thing - objects do quintuple-duty as hashtables, records, objects, classes, and modules. Arc is very similar to JavaScript in terms of the primitive data types available - they're both Scheme-derived languages.
The reason I'd term call this modules is that they don't have the implicit-receiver that classes/objects do, nor do they have constructors. Once you define a module, that's it, and they live in the global namespace. You could change things around pretty easily so that instead of immediately executing the closure containing the module's namespace, you define it as a constructor function. And you could probably then come up with some macro to expand to a message send, which passes the object as the first argument to any method defined in it. I think you'd be stuck with explicit-self though, like in JavaScript or Python, instead of the implicit `this` of Java.
Special operator is what they're called in CL. I don't know offhand what they're called in Scheme. But what it amounts to is that if only exists as a clause in the compiler.
