I'm not attached to the name, and have no objections to switching to 'socket-connect. It's only unfortunate that arc's native "open-socket" doesn't proclaim its server nature, so I figured the word "client" would help disambiguate.
I presented this at an agile conference in france - many java-family users in audience, so it's likely to be less relevant for you, but feel free to grab ideas/examples/text/whatever
I don't know scheme, but it might be for performance. The earliest iterations of rainbow used hashes for global symbols but profiling showed that was a bad idea. Now, each symbol object stores its own value, so there is no lookup, and stuff runs faster.
I don't understand how there cannot be lookup in both cases. The only difference I can guess is that in case of hashes you might have used strings as keys and when using symbols the lookup is done only by pointers. But that's the same in scheme if use use symbols as keys in hash table.
zhtw, your profile says you're building a lisp compiler, so I'm taking the liberty of exposing the innards of rainbow a little, it might be helpful:
public class Symbol {
String name;
ArcObject value;
// ... etc
}
Pieces of arc code contain direct references to these Symbol objects. For example, (car x) is implemented by something like this:
class Invoke_Sym_Lex {
Symbol fn; // points to the "car" symbol
LexicalSymbol arg;
public void invoke(...) {
fn.value.invoke(arg);
}
}
there is no lookup. The symbol is baked into the code. Lexically-bound symbols are more complicated, but they don't use hashes for lookup either.
As far as I can tell, this approach will support namespaces without any performance penalty, except perhaps at read/compile-time. Assuming arc gets namespaces one day ...
I notice I prefer euphonious names when I need to pick one even though I expect to talk arc rarely or never in conversation. It's probably easier to reason about variables when your brain doesn't have a side process figuring out how to pronounce them. I would run away from "ld" and "lb" for that reason. I would also prefer "fun" to "fn" because I bet there are psychological benefits from reading that word hundreds of times a day. Lots of fun. Could be a major selling point for arc.
> Lots of fun. Could be a major selling point for arc.
Ah ah, I really laughed reading this. And jokes are to be taken... seriously :-D [1]
> I notice I prefer euphonious names
I respect your preference of course, but since we are in a "what's your personal opinion" thread, I'll give mine.
When I think about "fn" in my head it sounds "F-N", like the Unix `ls'/`cd' sound "L-S" / "C-D". I actually like these "saccatero sounds". In English, how do you pronounce "ISP" or "BTW" in conversation? Aren't people saying "bee-tee-double U" sometimes?
---
1: I'm serious here. I'd have probably never got into computers if it was not fun. I'm fond of the acronym jokes ("Gnu's not Unix", the names of the Lisp dialects Nil/T/Eine/Zwei, etc.). I'm in love with the fact my computer is full of daemons, indians (Apache), penguins and the like.
You make a powerful point about cons cells being a more fundamental type than lists. I think if we really wanted english language words to describe the parts of a cons, "left" and "right" would be appropriate for what a cons is in isolation, but would unfortunately be meaningful only if you're using conses to represent binary trees. The beauty of a cons is that it's the smallest possible structure out of which one can build arbitrarily larger composites. And I'm not sure how valuable metaphors from the physical world are when contemplating abstractions - a cons is another degree removed from everyday reality than windows, buttons, dialogs, tabs, and menus are.
The dot ssyntax in this case is just what the caller would have to do if the callee expected a pre-testified arg:
(some testify.ch chars)
So the choice of dot instead of colon might be better for consistency - it looks like it's just inlining existing code.
I like it less this way, personally - it looks like "testify" is somehow part of the param name, whereas with "testify:test" the two parts seem more distinct, that "testify" is something you apply to "test" before proceeding with the function. But maybe that's just subjective.
I like your definition of table. The only advantage of 'obj is that keys don't need to be quoted. (Although sometimes that's a disadvantage too; the macro quotes them, so keys can't be determined at run-time)
