Newsgroups: comp.lang.apl
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!jtsv16!blister!itcyyz!yrloc!rbe
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: implementing @:
Message-ID: <1991Apr21.161301.9172@yrloc.ipsa.reuter.COM>
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
References: <19APR91.00433381@uc780.umd.edu>
Date: Sun, 21 Apr 91 16:13:01 GMT

In article <19APR91.00433381@uc780.umd.edu> cs450a03@uc780.umd.edu writes:
>There are various parts of J which are rather slow.  I've been looking
>
>One way to improve speed would be to selectively substitute faster
>expressions for overly general expressions.  I haven't explored this
>idea much, yet.
>
>Another way to improve speed is to re-do the underlying

Of course, special casing and embedding support for idiomatic expressions
in functional languages is one way to get lots of speed. In SHARP APL,
we obtained factors of 5-500 speedups for primitives such as catenate-with-rank,
base-value-with-rank, and so on. Too bad we never got time to finish that
work...

My J compiler is going to have some capabilities in this area -- it has to do
so, if it's going to be successful (fast, that is).

I think Roger's design as it stands is excellent for a prototyping platform:
Radical design changes can be propagated through the entire interpreter
with minimal effort. Once you start bolting special case code into an 
interpreter, the design tends to become frozen to a large extent.

Also, special cases DO take time, and given the limited budget (temporal
and otherwise) which J is being developed under, it is understandable that
correct operation takes precedence over speed. ( I am told that some
other language designers do not share this view...   8^}
)

Bob



Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada