Arc Forumnew | comments | leaders | submitlogin
1 point by almkglor 5679 days ago | link | parent

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