That's interesting that Haskell also uses the term "implicit". The differences seem mostly related to the type system. For example, since the variables are statically typed, it's easy for them to overload "let" to do dynamic binding with implicit parameters. Is there some other subtle difference that I'm missing?
The "it's always been called X before" argument would prevent us from ever improving the language by coming up with better names; we'd still be calling anonymous functions "lambda" instead of "fn" etc.
Er, see the post you replied to: that code I gave is precisely the same modulo syntax, but in Common Lisp it evaluates to 1 and in Haskell to 0. Essentially, Haskell's implicit variables don't allow rebinding/shadowing. It's a bid hard to explain, but look at the example and play around a bit and you'll see what I mean.
I have some code that defines the request variable req dynamically, so that instead of
(defop foo req
(pr (arg req "bar")))
I can say
(idefop foo
(pr (arg "bar")))
I found myself thinking in my own mind "OK, so here in this code I'm using req implicitly..."
Good names for concepts are always valuable, so paying attention to what my mind was calling this, I thought "Hmm, how about the name 'implicit variables'?"
Though I suppose if you have zillions of users you might not want to be using up your memory making Arc instances for each one.
There's no benefit to having more Arc instances than you have CPU's, at least in terms of using all your CPU's.
So you might assign each user to one of four Arc instances.
Having a particular user always go to one Arc instance is useful since you don't lose your in-memory data structures like fnid's for that user.
For communicating between Arc instances you don't have to use JSON, though you certainly could, you could use Arc's read and write to be communicating with Arc data instead.
It probably doesn't make a big difference either way.
I haven't done any testing along these lines, so I don't know what the actual answer is, but I don't think adding more Arc instances than you have CPU's would do anything except use up more memory...
edit: though I suppose it's possible that garbage collection times might not scale linearly... if it takes more than twice as long for the garbage collector to run on twice as much data, then a larger number of smaller processes might give you some kind of performance benefit.
One conceptions of a "type" is to consider it as a logical representation of a particular set of operations, and a value is a member of that type if it supports those operations. Under this conception, as you say, either string ports would need to be a subtype of ports with "inside" as an additional operation, or file ports ought to support "inside" somehow if file ports and string ports are to have the same "type".
Another conception is to consider types as merely a label that we can attach to a value when it's useful, one trick in a bag of tricks for writing concise code.
The label isn't a precise promise, any more than if I scribble "living room stuff" on a box when I'm moving is a promise that the box is only going to contain precisely and only living room items. It's just a convenience to remind me to dump the box in the living room. Likewise labeling a value as a "port" or a "string" is helpful in a function that I want to take different actions depending on the label, but I don't have to be labeling the value in excruciating detail just to do that.
Under this second conception, a proposal to make (type (outstring)) or (inside (outfile)) return a different value would be met with a question "how would that help me write programs more concisely?"
Of the languages that I'm familiar with, Haskell really takes the idea of a type as a mathematical set of operations and implements it seriously. I found Haskell elegant and intriguing, but when I tried to write applications I found myself spending way too much time writing extra code to make the type checker happy. Which is supposed to pay off in fewer bugs, but not many of my bugs end up having been type related, so it wasn't actually helpful to me.
So in my own experience writing applications, Arc's not having a strict "set of operations" conception of type has been a big win. At least for me. Certainly I enjoy writing programs in Arc much more than I did in Haskell.
Of course, someone who prefers Haskell would likely have the opposite opinion.
> "how would that help me write programs more concisely?"
Ok. This is after all the most relevant question.
But my point is although it's not necessary to worry about the difference between outport and outfile from the user's point of view, it's certainly impossible to ignore them when you implement these functions. You kind of have to since you need to know whether or not inside is allowed for a particular object. Whether to make this information visible for the user is another question.
That's good to know about being able to edit the first letter back to lowercase -- on occasion I've started a title with a function or macro name that should be uncapitalized.
That's cool. It's a neat idea that by default (if there isn't an explicit reason why you have to do something else), all interfaces can be HTTP, and as a bonus use JSON as your data interchange format...
Exactly. The concept is great. Even now when I am starting to learn haskell, the first thing I am doing checking out haskells' JSON parser to communicate via HTTP. Conceptually I can keep doing this and communicate easily across any language. And since SQL to URL is so basic I can re-use/apply dbslayer to any language too.
Is there a kind of program you'd like to be able to write?
By analogy, first you say you want to get into transportation, and someone says "OK, here's how to learn how to fly a plane, ride a bicycle, drive a car, pilot a submarine..." and you say, "oh, I'd really just like to learn to sail", and that narrows it down to something where it's easy to say, "oh, OK, here's where to go to learn to sail".
So if you think of a kind of program that would be useful to you, we can better suggest how to get started with the basics of doing that :-)
A program that counts words, periods, commas, sentences? That would be nice for my writing, or at least interesting. I've always wonder how many periods I've used....
Sorry, but that's really all I can think of. I'm not even certain I know what is and isn't a program.
