Arc Forumnew | comments | leaders | submitlogin
Arc packages, name spaces and function appending
4 points by tc-rucho 5434 days ago | 2 comments
I've been wondering for a while now, if packages will be implemented and how will the namespaces be. I've used Common Lisp for some time, and I really think the per-package inner (for package's guts) and exported namespace is a win, since a loaded package would not accidentally redefine any function in the current namespace. Many of us would not want to call every function with a package prefix, but that's where namespaces merging would take place. I know I'm explaining something that's pretty familiar to any Common Lisp user, but anyway, I think ASDF's model is a win. It's not clear the true win about having an inner and an outher namespace at first sight, but when you grab a decent suite like slime, with tab autocompletion for functions and other nicities, having two namespaces keeps it clean of stuff you don't want to mess with.

Regarding the syntax that would be used. I suggest the following: ASDF's package naming conventions. Having "package::function" for inner namespace and "package:function" for exported (or outher) namespace, that is. For functions concatenation, I suggest the following since this would collide with current syntax: "(fn1&fn2&fn3 parameters for fn3)". Since '&' usually means "and", and it's a widely used way to exec multiple commands in sh, bash, etc.

I know that redefining this at this stage would be awkward, but may I quote some PG's words: "[..] we're going to keep acting as if we were the only users. We'll change stuff without thinking about what it might break, and we won't even keep track of the changes.[..]" <-- and I couldn't agree more :)

Sorry if I missed some news about these topics here and there, but it couldn't be helped...

Edit: Another option would be to have just one namespace, and import only those definitions we care about from the loaded packages... I think this would be cleaner...

TC.



2 points by shader 5433 days ago | link

The only problem with your naming system is that colons are already taken as syntactic sugar for function composition. If you're interested in package systems for arc, you could look into what almkglor did on Anarki. It was a pretty thorough overhaul of most of arc, but I don't think it's supported anymore.

-----

1 point by almkglor 5427 days ago | link

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 ^^

-----