Subject: Some Suggestions and Thoughts about Arc

From: Shlomi Fish <[email-masked]>
Date: Wed, 8 May 2002 05:32:17 +0300 (IDT)

Hi!

First let me congratulate you for trying to make a truly usable and brief
LISP dialect. I hope this initiative takes off. As of now, I only code in
Scheme and CL for "academic" purposes. (part of my SICP homework, or to
test new things) I think I like Perl more than LISP, but I still think I
could use a LISP dialect in which I don't feel that there's absolutely
nothing useful I can do with it. (in the short time with which I wish to
accomplish what I want to do.)

Here are my suggestions. Feel free to embrace them or ignore them. IMO,
putting every feature under the Sun in one language (which seems to be
the wave for Perl 6) is not a good language-design methodology. But these
are the features and thoughts that I pondered:

(you should excuse my inconsistent Scheme-like syntax, because I'm not too
much familiar with Arc as of now)

1. Support for Namespaces Proper.
---------------------------------

By namespaces I mean something like C++'s or Perl's. Assuming:

1. (ns ... ) puts bindings in their own  sub-NS
2. (ns-import the-ns symbol1 symbol2 ... ) imports symbols from a
namespace.
3. :: is the namespace mangling symbol meta-component.
4. Just for the heck of it top:: is a meta-namepsace for the top one,
this:: is for the current one, and up:: is for one namespace above.

Something like that should work:

(ns sort
	(def qsort ...
	)
	(def partition ...
	)
	(def merge-sort ...
	)
	(def merge ...
	)
) ; End of merge-sort namespace

(ns-import sort qsort merge-sort)

(= sorted-array (qsort myarray))
(= sorted-array2 (merge-sort myarray2))
(= combined-array (merge sorted-array sorted-array2)) ; Error!
(= combined-array (sort::merge sorted-array sorted-array2)) ; Better.

I don't think I should explain too much more, because I can safely assume
you are familiar with namespaces. As of now, Scheme and CL do not support
those name-mangling features. CLOS and its equivalents are not enough AFA
namepsacing is concerned.

2. Are Array/DB/etc. Subscripts going to be lvalues?
-----------------------------------------------------

Where in Perl (or in C) the following works:

$myarray[$i] += 5;

Will the following work in Arc:

(+= (aref myarray i) 5)

This is much more humane than:

(vector-set! myarray i (+ (vector-ref myarray i) 5)) ; %-)

Now, what about array slices and ranges, hash slices, etc?

3. Mundane Functions returning lvalues:
---------------------------------------

While we're at it, are we going to have lvalues propagate all the way?

Will the following code work:

(= (min a b) (max a b))

This is just a nice way of writing:

(if (> a b) (= b a) (= a b))

4. The equivalent of Perl'w -w switch - warn on experessions that amount
to nothing:
-------------------------------------------------------------------------

I'd like something like that:

(define (myfunc callback b)
    callback b           ; Warning - callback is in a separate statement that
			 ; does nothing.
)

(define (myfunc callback b)
    (callback b)      ; OK
)

I don't think it is hard to believe, but there was a case when such lack
of parenthesis caused my code not to work.

5. OO as a standard way of doing things
---------------------------------------

In Perl, most objects, even those that are not planned to be inherited
are encapsulated using the language's standard OO conventions. This gives
two things AFA I can see:

1. It makes sure the API their supply can be instantized.

2. It gives a standard and consistent way of using them. One does not need
to learn a new set of conventions for every API.

I think Arc should have a "standard" object system, similar to CL's CLOS.
Furthermore, it should use it wherever appropriate, to make sure the APIs
it supplies are consistent.

Again, there's no need to make it overly OO. In Perl, for example, arrays,
hashes, strings, sockets and many other things are not objects.

----------------

That's it for now. Please acknoweledge that you have read this message,
just for my peace of mind.

Regards,

	Shlomi Fish

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"