Arc Forumnew | comments | leaders | submitlogin
5 points by nostrademons 3761 days ago | link | parent

Hahahaha no. Lisp-1 + unhygienic macros + no module system = a world of pain when projects grow beyond a few thousand lines, even ignoring the lack of user-defined data types. The lack of structured data is less of a problem than it might seem, because you can write accessor functions that abstract away whether it's stored in a list or hashtable and the precise keys, and just use those. The issue is namespace-pollution from all those accessors.

I'd kinda like to see Arc grow some sort of module system - even a very simple dictionary-based system like Python's or JavaScript can go a long way towards making larger programs tractable. Come to think of it, I think you could emulate JavaScript's system with closures and hashtables. Just wrap every module in a closure, which binds a hashtable to the module name and inserts each function into the hash table:

   (set My-Module-Name (table))
   (= (My-Module-Name 'foo) (fn (arg1 arg2) ...))
   (= (My-Module-Name 'bar) (fn (arg) ...))
   (= (My-Module-Name 'baz) (fn () ...))
  ] 'ignored)
A little macrology could make this a bit more elegant:

  (module My-Module-Name
     (private my-private-method (arg1 arg2) ...)
     (public my-public-method (arg1 arg2) ...)
     (public my-other-method (arg1) ...))
The macro code would look something like this:

  (mac module (name . spec)
    (with (car-is (fn (sym) [is sym (car _)])
           public-forms (keep (car-is 'public) spec)
           private-forms (keep (car-is 'private) spec)
           make-public [`(= (,name ,'(cadr _)) (fn ,@(cddr _))]
           make-private [`(,(cadr _) (fn ,@(cddr _)))])
          (set ,name (table))
          (with ,(mappend make-private private-forms)
             ,@(map make-public public-forms)))] 'ignored))
Now I kinda want to install MzScheme and try it out...I've been working off the tarball source only. :-)

4 points by chandler 3760 days ago | link

As far as I can tell, having a purely closure-based module system won't actually solve the lisp-1 redefinition problem; to use your module system, some manner of compile-time token capture is necessary. Essentially, the problem is:

  (= my-module
     (let obj (table)
       (= (obj 'rem-xs) (fn (s) (rem #\x s)))

  ((my-module 'rem-xs) "abcxdefxghi") ;; => "abcdefghi"
Now, suppose I redefine "rem" at the toplevel to be like the BASIC rem, or a remark function that ignores its parameters:

  (def rem args

  ((my-module 'rem-xs) "abcxdefxghi") ;; => nil
I think Arc uses a lexical scope, so this problem shouldn't show up in the following example:

  (aload 'my-module)

  (let rem (fn args nil)
    ((my-module 'rem-xs) "abcxdefxghi"))

  ;; => "abcdefghi"
However, you would need to be careful when attempting some kind of dynamic import:

  (let rem (fn args nil)
    (aload 'my-module)
    ((my-module 'rem-xs) "abdxdefxghi"))

  ;; => nil
I think the former (though not latter) problem can be mitigated by shadowing all functions/globals you want to stay invariate, as in:

  (= my-module
     (with (rem rem
            table table
            fn fn
            obj (table))
       (= (obj 'rem-xs) (fn (s) (rem #\x s)))

  ((my-module 'rem-xs) "abcxdefxghi") ;; => "abcdefghi"
However, as you can imagine, this will get unwieldy fairly quickly (like you, I've downloaded the arc0.tar file, but not actually bothered to downgrade my copy of plt-372; i.e., I'm not sure how canonical the provided arc snippets are).

Of course the ignored caveat is this: so many bloggers are up in arms over this point, it's presupposed that being able to change core library functions is a defacto terrible thing--at work, where we have a massive C/C++ codebase running on some unmaintained, sourceless, legacy APIs, being able to (for example) add/fix methods in some of the base classes would be a significant time-saver.

I think Arc as-is makes it a bit too easy to shoot yourself in the foot; however, I'm firmly in the camp that being able to update core functionality should be allowable.

Also, for better or worse, look at emacs: a massive, mature system that contains no module/namespace system, no closures, and, due to its dynamic scope, would fail each of the above examples. I'm not saying I hope Arc emulates these (lack of) features, however, it's still proof that they're not necessary for large, real-world (whatever that means) projects.


3 points by cpfr 3759 days ago | link

The big problem is def and =s update a global symbol table. They are not like Scheme and define. If def obeyed local scoping rules and could be shadowed, the problem is shadowing has to be done explicitly. That is why this is painful and unwieldy. Ultimately, this needs to be fixed or Arc will be needlessly crippled.


2 points by jdvolz 3761 days ago | link

What kind of syntax should we use to denote the module? Something like:

(module::function args)

This idea comes from Ruby, though I am not sure it necessarily plays well with the function composition operator (func1:func2). I wouldn't want to use -> or "." because of the concept collisions those would create. Could we just use something that doesn't have a mainstream meaning, like (module#function) or (module>>function)?


1 point by nostrademons 3761 days ago | link

module::function looks good to me. Someone else suggested allowing user-defined syntax characters; this would be a good use-case. It only has to expand into (module 'function), so the implementation is basically trivial.


2 points by cpfr 3761 days ago | link

Why not module:function? Abuse the property that : stands for composition. A more lispy solution of (module function) might also work, and its only an extra character. Though if I were going for an Arc solution, it should probably be (bin fn) or (md fn).


1 point by randallsquared 3758 days ago | link

In case you hadn't noticed, there's a sketch of a module system in the arc-wiki repo that does exactly this, now.

It doesn't solve the problems mentioned in this thread, of course.


1 point by greatness 3761 days ago | link

This seems like it'd be closer to classes/objects than modules.


2 points by nostrademons 3761 days ago | link

In JavaScript they're the same thing - objects do quintuple-duty as hashtables, records, objects, classes, and modules. Arc is very similar to JavaScript in terms of the primitive data types available - they're both Scheme-derived languages.

The reason I'd term call this modules is that they don't have the implicit-receiver that classes/objects do, nor do they have constructors. Once you define a module, that's it, and they live in the global namespace. You could change things around pretty easily so that instead of immediately executing the closure containing the module's namespace, you define it as a constructor function. And you could probably then come up with some macro to expand to a message send, which passes the object as the first argument to any method defined in it. I think you'd be stuck with explicit-self though, like in JavaScript or Python, instead of the implicit `this` of Java.


3 points by mst 3760 days ago | link

... and scopes.

Javascript's scope chaining is one of my most and least favourite things about the language. But it's a damn clever approach once you get it.