J to APL2 
Author Message
 J to APL2

[This message is converted from WPS-PLUS to ASCII]

In a recent CLA posting Alan Graham said.

Quote:
> I have a challenge for you in J. (For you it should be easy!)
> Write an APL2 to J translator. Nothing robust, just something to spark
> interest.

I think a J to APL2 compiler-preprocessor would be of greater
utility.  Basically such a facility would translate a
subset of J to a subset of APL2.  I expect you would have
to provide a set of APL2 cover functions and operators to
emulate fundamental J facilities like the rank conjunction.

My reasons:

1)  J has standard control structures.  Complex explicit
    definitions are far easier to follow in J than their
    corresponding branch laden APL equivalents.

2)  Automatic code portability.

3)  Data portability -

    J's grounded arrays are easy to emulate in APL2,
    and indeed any APL with nested arrays, it's not so easy to
    go the other way.

4)  J provides an inexpensive but very complete APL development
    environment.

    I've used expensive PC APL's that lacked essentials like
    complex numbers and automatic boxing of nested arrays.

5)  You could execute J algorithms in environments where J is
    not officially supported, e.g. mainframes.

6)  Such a tool would offer a migration path for "endangered" legacy APL
    code into the modern J world.

7)  Finally, the most important reason, I would never have
    to code in APL2 again (debug maybe!)

Any takers!!



Sun, 25 Jan 1998 03:00:00 GMT  
 J to APL2

Out of respect to APL2ers from APLBUG I'll bite.

Actually I haven't programmed in APL in years ... but here goes.
.
.1)  J has standard control structures.  Complex explicit
.    definitions are far easier to follow in J than their
.    corresponding branch laden APL equivalents.

  True, but the statments it has are somewhat limited. For
  example, J does not have "for" statements.

  APL2 will have control structures someday soon. There
  have been several proposals (some even implemented).

.2)  Automatic code portability.
.
  True. But although J will compile on nearly any platform,
  software development in J has focused mostly on building
  a commercial product for Intel boxes running Windows.

  The J interpreter still has some pretty slow verbs, such as roll
  and deal.  Much slower than the APL2 counterparts.  And the model for
  the polynomial rootfinder worked badly too.

  Also, APL2 has lots of nice bells and whistles on both OS/2
  and Sun platforms. That is, it has a nicer session manager
  (except for j-interaction-mode  there isn't a SM for J for the Sun)
  and several features J does not have. For example, functions
  for communicating with process on other machines over a network,
  fetching files, and mainframe SQL query support.

.3)  Data portability -
.
.    J's grounded arrays are easy to emulate in APL2,
.    and indeed any APL with nested arrays, it's not so easy to
.    go the other way.

 Then this is a plus for APL2 then right? You are saying it can do
 what J can do and more.

 Of course, while we are comparing J and APL2 perhaps we should
 note that TCL is portable over UNIX, Windows, and the MAC. And
 if portability is your big thing then forget APL.

.4)  J provides an inexpensive but very complete APL development
.    environment.
.
.    I've used expensive PC APL's that lacked essentials like
.    complex numbers and automatic boxing of nested arrays.
.
 J is not inexpensive when you look at it from the point of
 view of the cost of the Professional Version of J.  That's
 about 400$. So while this is inexpensive compared to Manugistics
 or Dyalog APL it is not compared to APL2 which, with the same
 features as J, sells for 190$. (Of course you have to buy into
 OS/2.)

 And if you are programming on a UNIX box and you want a version
 of J with control structures that will cost you 350$-400$. Not
 exactly pocket change.

 Hum... considering j7.0 source is pd and that there is a
 pd Visual-J for Windows, J comes out ahead. I guess.

.5)  You could execute J algorithms in environments where J is
.    not officially supported, e.g. mainframes.
.
 Hum... Don't most IBM mainframes come with APL2? I recall
 hearing about a survey saying that at 90% of IBM mainframe sights
 there were usually some people (usually a few technicians) programming
 in APL.

.6)  Such a tool would offer a migration path for "endangered" legacy APL
.    code into the modern J world.
.
 If J is the legacy to APL we are all going to end up changing careers.
 We'll all end up as musicians, lawyers, or actors.

 More ....

 APL2 has less terse and more complete documentation than J :

    For one thing, K. Iversons books focus too much on clever one
    liners, not on how to develop real applications. I purchased
    Ken's most recent book and found that it was a rehash of the
    his other J texts and Rogers posts on the net.

    Also, an aside on J doc ....

      The documentation on calling DLLs in the Windows product,
      is, it appears to me, diliberately confusing. And to make
      matters worse ISI does not provide simple compilable examples.

      The DDE dialogs in the examples time out on real applications
      and so are a waste for using as a template for real applications.

      There is not DDE dialog example for communicating with Excel ;
      probably the most widely used software product Microsoft has
      except for its Windows OS. (This is strange since J ought to
      be the perfect product for a spreadsheet user who wants a
      more powerful programming tool.)

      Finally, the demos ought to be improved by moving from the j6.2
      control structures to J release II structures, you have to know J
      fairly well to decipher Burke's code to figure out all the undocumented
      Windows features of J.

 APL2 has better internet support than J :

    For example, I reported that a beta version of J could
    only transfer 2400K of data to Strand Software. They
    never got back to me except to say that they would
    look at it.

    Similarly there are some quirks about putting ISI
    graphs in a Window. This can make it so that what
    you put into a Window is not exactly centered.

    I reported this and Strand didn't respond on it either.

    Naturally when I purchased my first version of
    J release II, the low DDE data exchange capacity
    was still a problem.

    And the graphing quirk is *still* there :)

APL2 has better marketing and a wider programming audience.

    At APLBUG meetings there are almost always
    more APLers than Jers.

 J has two nice features John didn't mention :

 (1) It is easy to integrate your own C functions as
     primitives to the J source.

 And

 (2) That, since the source is available, it may be possible
     to modify the rank operator in machine specific ways
     to allocate computation over multiple processors.  

e-



Tue, 27 Jan 1998 03:00:00 GMT  
 J to APL2
Some comments on this thread:

Quote:
>.1)  J has standard control structures.  Complex explicit
>.    definitions are far easier to follow in J than their
>.    corresponding branch laden APL equivalents.
>  True, but the statments it has are somewhat limited. For
>  example, J does not have "for" statements.

The control structures currently in J are a small set that was
believed adequate. In practice, I find they work well, and are a great
improvement over APL branch. However, there is nothing to prevent more
control structures being added later on.

Quote:
>  True. But although J will compile on nearly any platform,
>  software development in J has focused mostly on building
>  a commercial product for Intel boxes running Windows.

This is true of most commercial software development. But the full
Windows system has been ported to the Mac, will run under OS/2, Windows
NT and Windows 95, and is currently being ported to UNIX.

Quote:
>  The J interpreter still has some pretty slow verbs, such as roll
>  and deal.  Much slower than the APL2 counterparts.  And the model for
>  the polynomial rootfinder worked badly too.

J is a newer language than APL, and has less effort put into optimization.
But there have been great improvements made over the last year, and the
current performance is comparable to commercial APLs. Indeed in recent
threads on c.l.a., J programs typically outperformed APL.

Quote:
>.    J's grounded arrays are easy to emulate in APL2,
>.    and indeed any APL with nested arrays, it's not so easy to
>.    go the other way.

I'm not sure this is true. For example, J distinguishes 4 and <4. How
could this distinction be easily emulated in APL2?


Fri, 30 Jan 1998 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. JS-EAI with *JS*-callback

2. js.exception 3279.js

3. APL2/2 to APL2/W95/NT

4. NB. gray.js: a J verb that generates a grayscale postscript image from a 2d array

5. lapackTest.js

6. profile.js

7. J script file profile.js

8. JS valueOf() in RB ?

9. JS for functional programming?

10. JS for functional programming?

11. prefs.js question

12. JS / VRML / HTML / camera binding

 

 
Powered by phpBB® Forum Software