Strictly speaking, it doesn't need to be so thorough.
It's possible to make the contexting system be less aggressive about putting symbols in packages.
As an explanation, contexting performs the following transform:
; Arc-F code!
(in-package foo)
(using <arc>v3)
(interface v1 public)
(def private (x)
x)
(def public (y)
(private y))
; equivalent transform!
t
t
t
(<arc>def <foo>private (<foo>x)
<foo>x)
(<arc>def <foo>public (<foo>y)
(<foo>private <foo>y))
Because of its aggression, everything gets to be a pretty thoroughly pushed to some package.
However, you can reduce the aggression instead, at the cost of declaring private functions:
; Anarki-on-arc3 code!
(in-package foo)
(using <arc>v3)
(internal private)
(interface v1 public)
(def private (x)
x)
(def public (y)
(private y))
; equivalent code!
t
t
t
t
(def <foo>private (x)
x)
(def <foo>public (y)
(<foo>private x))
In short, instead of assigning unpackaged symbols to the current package, it leaves unpackaged symbols. This retains as much back-portability with ArcN as feasible.
However you still need to force contexting in your REPL/load, i.e. RCEPL, read-contextify-eval-print loop.
I won't be working on Arc-F, since I have my own project now, and stefano is squeezing me to get a REPL on it some time soon ^^
In the above link, pg describes the problem as being in the fact that he was using "a four variable list to destructure on a five value description of the field."
The above bit of code appears to be the "five value description". It's a function creating a data structure specifically for the particular user and post, making some data showable/not showable and modifiable/not modifiable.
The only time that this particular variable is used is in calls to a 'vars-form function. This function is in app.arc <insert snarky comment about badly disorganized code here>:
The succeeding line has a "(and mod v)" line, which might be correctly "(and mod valid)", where valid is the missing variable in the destructure. <insert snarky comment about pg's Arc-community-building skills here>
> continuations, so an Arc-like web server might be more challenging.
Arc's server doesn't actually use continuations - it uses functions that serve as continuatinos. There's no call to 'ccc or any of the wrapping forms in srv.arc (at least none that I remember)
> The concurrency story is particularly interesting given the proliferation of cores and slowing of GHz.
This is true and I think the "extra-cycles-to-waste" property expected by PG isn't going to put out in a hundred years.
> state of the art VM/JIT technology
Forget the libraries. This is what's scary about any JVM language.
"Arc's server doesn't actually use continuations - it uses functions that serve as continuatinos. There's no call to 'ccc or any of the wrapping forms in srv.arc (at least none that I remember)"
That's right, no 'ccc. That's why I could implement it so easily in Lua (no real continuation in Lua either). As for TCO, I'm not sure it's a real problem in this case. Sure, a lot of simple functions are written in a recursive style, but they can be trivially rewritten in an iterative style.
As an aside, arc-f currently handles loading by wrapping a sizeable bit of 'load in 'atomic, but this is unnecessary, I think, if I use a thread-local for current-load-file* and friends.
> Regarding the use of interfaces to specify the language version: have you ever considered making the language itself a package?
Uh, yes. That's how it's already done. That's why arc.arc is itself a package. In fact, when you say '(in-package foo), the only thing that the contexter will add to the newly-defined package foo are the Arc axioms: '<axiom>fn, '<axiom>if, '<axiom>quote etc. That's why you have to declare '(using <arc>v3) for each package - because otherwise the language doesn't actually import arc.arc
Edit: Ultimately (and this is another disagreement with PG) arc.arc is a library, not part of the language. It's like the libc in this respect. Because you see, we already had the 150-year language 50 years ago.
Edit2: as an aside, the package system even lets you export a binding for 'quote, 'quasiquote, etc. In fact, once we have defined a formal method to add ssyntaxes, it would be possible to add support for `(let foo# ,foo (something foo#)) in a library, not in the language. How? By defining an export for 'quasiquote, say (interface v1 <auto-uniq>quasiquote), where <auto-uniq>quasiquote is a macro that expands to <axiom>quasiquote
> In my opinion the grain should be as fine as possible, so that you can use embedded DSLs whenever possible (like w/html or LINQ).
Hehe. It's in the arc-f/ directory more for historical reasons than because it's not a library, and also because it's treated specially (it gets precompiled to Scheme bytecode, for example).