Newsgroups: comp.lang.apl
From: gurr@swag.0 (David Gurr)
Subject: Re: Structured APL requires abandoning dynamic scope?
In-Reply-To: wchang@genome.lbl.gov's message of 11 Sep 1994 07:12:36 GMT
Message-ID: <GURR.94Sep12193821@swag.0>
Lines: 73
Sender: news@mr.med.ge.com
Nntp-Posting-Host: swag
Organization: GE Medical Systems, Magnetic Resonance
References: <34sanbINN1iv@porto.cshl.org> <34stpt$mo0@cantaloupe.srv.cs.cmu.edu>
	<34ual4$ji4@overload.lbl.gov>
Date: 13 Sep 1994 02:38:21 GMT

In article <34ual4$ji4@overload.lbl.gov> wchang@genome.lbl.gov (William Chang) writes:

   From: wchang@genome.lbl.gov (William Chang)
   Newsgroups: comp.lang.apl
   Date: 11 Sep 1994 07:12:36 GMT
   Organization: Cold Spring Harbor Lab
   Reply-To: wchang@cshl.org (William Chang)
   Keywords: Object oriented

   I'd very much like to see a rigorous comparison between an f.p. or LISP
   interpreter and APL.

After one factors out the difference in data types (APL arrays are not
exactly the same as Common Lisp's)  The difference will be interpreted
dynamicly scoped vs. incrementally compiled.  This is a difference one
can easily test with a Common Lisp compiler.  CMU's CL is freely avail.
so if you are really interested, try it out.  Or perhapse ask a frendly
c.l.lisp'er to try it out.

   Sure there are nice algorithms (can you provide some
   pointers to _recent_ ones?) but implementation is another matter.  I'm not
   arguing dynamic scope is more efficient--I don't know!  I do know that APL is
   _more_ efficient than other interpreted languages (yes mostly due to the array).


As for pushing the limits on array code check do check out Jay Sipelstein
and the rest of the NESL crew's work.  Very nice performance figures.

   >How about a good type system?  This is the way that this problem
   >is solved in the academic/functional world.  As a bonus, adding types
   >to an APL-like language will radically simplify compilation.

   You are certainly talking about designing a new language.  A good thing.
   Maybe a new paradigm, type systems for really efficient but flexible arrays.

Maybe not a new paradigm.  APL's are already used to rank and shape which are
type atributes in other languages.  The trick would be to use type the same
way we already use rank and shape to do data driven processing.

   >In what way will making a language "object-oriented" solve the problem
   >of structures with lots of fields?  This is precisely where types can
   >help you.  You just bundle everything into a structure, give it a type,
   >and work with it.

   The point of OO, is that one does not pass an object (a really big and
   complex structure) to a function, but rather the reverse--send a function
   ("message") to an object.

Sending a message is the retoric.  More reacent OO languages (CLOS being
one of them) have reverted to calling them generic functions.

   Context stays with the object.  It is elegant,
   structured, and efficient.  Types/structures are inherently inflexible
   (of course not necessarily a bad thing) and possibly inefficient for an
   interpreter (APL has no pointers; structs have to be copied).

   >I would suggest that adding a type system and structures to future
   >versions of APL is a MUCH less radical change than adding OO features
   >to the language.

   I don't know about types, but structures are commonly simulated in APL, i.e.
   nothing really new.  They fall apart when things get really big or complex;
   it's not clear to me that built-in types and struct would change that.

Try ML (CAML is free and runs on eveything) for a taste of what APL with types
might be like.  Like J, it takes some getting used to but does grow on you.
ML has a strong type driven code style that is hard to give up once you learn it.

Or try NESL, if you cant find a port of CAML for your Cray.

   -- Bill Chang (wchang@cshl.org)

-David Gurr

