Arc Forumnew | comments | leaders | submitlogin
Packages/modules/namespaces/classes/units
4 points by vrk 6111 days ago | 3 comments
If you really are taking Arc to a new direction in programming language design, it would be handy to unify all the different concepts for large-scale modularization. By this, I mean what are called classes and packages in Java, packages in Perl, modules in mzscheme, namespaces (and classes) in C++, units in Pascal and Ada, and any other name other languages have for them.

There has to be some small or tiny set of common concepts that can be used to implement all of those. Perl comes, in my opinion, close. Perl provides packages, which are really just namespaces, and you can import and export names from other packages. It is possible to bind a scalar (variable) reference into a particular package by "blessing" it into the class, after which you can use the familiar arrow syntax to call functions on it, and fake it's really an object (in the object-oriented sense). If a function foo() is defined in package A, and you bless variable $v to A, $v->foo() then calls foo() in class A with an implicit first argument $v (A::foo($v)).

Perhaps it's not the best way to do it. I have only briefly read about mzscheme modules, but they seem to support importing and exporting at least. Maybe it's enough; maybe the only thing needed is light-weight namespaces.

Yes, you could do all this with macros and closures, and as I understand it this is how it's implemented in many Scheme implementations (since the standard up until R6RS didn't provide a module mechanism). But it feels this is a deeper design issue that should be taken in to account. Are we missing something?

I certainly hope Graham is not going to include something as large as CLOS, or any particular object-oriented framework, in the language. That would miss the goal entirely.



1 point by t1m 6111 days ago | link

Erlang has modules. It's ability to allow user defined loading mechanisms for them is a nice feature:

http://www.erlang.org/doc/man/erl_prim_loader.html

-----

2 points by partdavid 6111 days ago | link

Maybe arc could also provide online code upgrades as well.

I like the idea of qualified names (namespaces for things) but prefer it to be divorced from the name of the resource where you find it. For example, in Perl and ruby I can require 'coolstrings.rb' which doesn't have anything to do with a "coolstrings" namespace or class but does change the way strings behave. It also provides a way to elegantly implement pragmas.

-----

1 point by ryantmulligan 6110 days ago | link

Live code upgrades is a great feature. Lisps already support this to some degree. If you make an app and expose a REPL on some local port then you can recompile functions on the fly. I'm not sure how it handles the current execution stack when this happens though.

-----