Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!howland.reston.ans.net!wupost!decwrl!decwrl!csus.edu!sfsuvax1.sfsu.edu!vpcsc4
From: vpcsc4@sfsuvax1.sfsu.edu (Emmett McLean)
Subject: Re: Seek help using lrx
Message-ID: <1993Jun1.081804.24215@csus.edu>
Sender: news@csus.edu
Organization: San Francisco State University
References: <1993May28.011134.17334@csus.edu> <1737@kepler1.rentec.com>
Date: Tue, 1 Jun 1993 08:18:04 GMT
Lines: 68

In article Andrew Mullhaupt writes:
> 
> In article Emmett McLean writes:
> >
> >I've been looking at translating the following program into C :
> 
> >And I've come up with the following :
> 
> >static F1(kcreate){A z,a,b,c;I t;
> > a=(A)iota(sc(0));
> > a=(A)lrx(box(scc('a')));
>  
> ... rest of the "Arthurized Version" deleted.
> 
> >I would have to define a verb, easy to do but bad programming
> >style.
> 
> Honestly now. Where can programming style possibly be a concern for you
> when your C code is transliterated APL?

  The difference between efficient and inefficient transliterated APL.
  
> Does this make any more sense than the people who write transliterated 
  FORTRAN in APL? 

  If their implementation of FORTRAN was written in APL and they
  where hacking the source to make FORTRAN do something it couldn't
  already do there would be no difference -:)
>
  
>This is the challenge: If there is any advantage to writing transliterated
>APL in C, such as performance, etc., then it is a pure and direct indictment
>of interpreter technology. What can the C compiler do that your APL (J)
>system should not also do for you?
>

 Keyed files have already been implemented as verbs. I like the idea
 of implementing this in C because these utilities have proved to be
 useful in other dialects of APL.  I would find them very useful.

> >If you need C for performance, then it should not make any sense to do
> the iota() on the C side; so why is it there?

 In this instance I do not need C for performance. In other programs,
 such as the real svd decomposition and the combinations hacks I posted,
 there wasn't much transliterated APL.

> Furthermore, we are certain
> to expect that the lrx line has a side effect _depending on the value of a
> or *a_ otherwise the line a = (A)iota(sc(0)); is dead code. It is not good
> to let this pass without any comment - think what someone who knows C will
> wonder when they see this? What's worse, it is not at all apparent which
> of the functions lrx(), box(), or scc() know about what you did to a or how.
>
> So from the programming style point of view, your C code is insane. And
> since the problem is that your interface doesn't clearly reflect what
> you're doing or what you're doing it to, it is _predictable_ that your
> question comes up.
> 
 You're right. The line (A)iota(sc(0)) is dead code. I turns out that
 lrep does what is needed without any side effects. In this instance the
 interface is somewhat thought out. The best explanation of why
 this question came up is mostly that I am still getting familiar with
 the source.

 -Emmett


