APL2J ?
pineapple
already exist?
1) APL to J translator (a more difficult proposition)
2) APL to J symbol substitution utility (easier)
3) Etc.
As to #2, it would simply take an APL symbol (i.e. ⍴) and change it to
J ascii (i.e. $). Note that I understand this would not transform an
APL program into a J program (necessarily), nor do I (necessarily)
care about that. But it would allow one to "write J as APL," at least
somewhat.
Just as a joke, I came up with several lines of APL that would
substitute a few APL symbols into J. Here is a sample "joke" run:
apl2j '3 3⍴⍳9 ⍝blahblah'
3 3$ i. 9 NB. blahblah
Is this "reasonably doable" on a larger scale? Has it been done?
Pitfalls? Headaches?
Thanks.
Richard
> Pitfalls? Headaches?
>
> Thanks.
You can refer to papers by C. Burke and R. Hui about this topic.
Access via the J wiki.
I have a part finished J script that produces a table:
J phrase, primitive, weigandAPL, offset in {quad}av,,,,
I use it mostly to go from J to APL
(its not easy)
I plan to put it in the J wiki very soon now :-)
Pls post if it is of interest, and I can lift the priority.
pineapple
> You can refer to papers by C. Burke and R. Hui about this topic.
Looked, couldn't find the paper in a reasonable amount of time, but
will look again when I have more time. Thanks. (Is the paper about
conversion from APL to J?)
> I plan to put it in the J wiki very soon now :-)
Interesting. I seem to be going the other way (APL → J). Don't know
if this is a waste of time or now, but I wrote more code, thus more
APL symbols are now being "translated." I have no idea whether I am
reinventing the wheel, or whether there is some hidden complexity or
pitfall I am unaware of.
This is off the top of my head, but I think going my direction (APL →
J) is probably easier than going your direction.
If you are interested in having what I am "doing" (*cough*) compliment
what you are doing, post back here.
Weirdly enough, I just noticed that I will probably be able to pass
the source of my APL2J symbolic substitution utility (written in APL)
through itself, thus winding up with a J version of the program.
Dick Bowman
> [... deleted ...] or whether there is some hidden complexity or
> pitfall I am unaware of.
>
> [... deleted ...]
There is.
Richard
> On Sep 8, 3:21 pm, Richard <hil...@melbpc.org.au> wrote:
>
> > You can refer to papers by C. Burke and R. Hui about this topic.
>
> Looked, couldn't find the paper in a reasonable amount of time, but
http://www.jsoftware.com/jwiki/Articles
APL and J (pdf) Chris Burke
http://www.jsoftware.com/jwiki/Articles?action=AttachFile&do=view&target=aplj.pdf
J for the APL Programmer Chris Burke and Roger K. W. Hui (updated
version in wiki)
http://www.jsoftware.com/jwiki/Doc/J4APL
pineapple
you were referring to. Thanks.
--
"Richard" <hil...@melbpc.org.au> wrote in message
news:01a1a15a-290d-4b3b...@y28g2000prd.googlegroups.com...
http://www.jsoftware.com/jwiki/Articles
Thanks very much for this. I am in the process of learning J (something I
try once in a while and get just "so far" before other things come up, but
have an APL background. However it is with the old STSC version and as I am
retired, the cost of a newer APL isn't warranted for my playing about.
Articles that you have given will help considerably.
--
Don Kelly
dh...@shawcross.ca
remove the x to reply
Nick
> 1) APL to J translator (a more difficult proposition)
An APL to J translator is quite doable, however
1. It could work only with a rather restricted subset of APL,
2. It would translate only to a rather restricted subset of J,
3. You may need to do some phony encloses of scalars, etc.
It is not hard, but not a direct string search and replace either.
Going in the other direction, J to APL, would be more difficult (and/
or more restricted)
Is there a complete (as possible) comparison table of APL and J
operations published somewhere?
Chris Burke
> > 1) APL to J translator (a more difficult proposition)
>
> An APL to J translator is quite doable, however
> 1. It could work only with a rather restricted subset of APL,
> 2. It would translate only to a rather restricted subset of J,
> 3. You may need to do some phony encloses of scalars, etc.
>
> It is not hard, but not a direct string search and replace either.
It would be very hard to write an APL to J translator that gave
acceptable results. The problem is not so much translating individual
operations, but translating APL expressions into corresponding J
expressions. Consider Example 2 from APL and J, that multiplies each
column of a matrix by a vector (http://www.jsoftware.com/jwiki/
Articles):
M34 {times} {transpose} ({rotate}{shape}M34) {reshape} V3 / APL
M34 * V3 / J
Clearly a machine translator is not likely to get the correct J
expression from the APL.
> Going in the other direction, J to APL, would be more difficult (and/
> or more restricted)
>
> Is there a complete (as possible) comparison table of APL and J
> operations published somewhere?
Not that I know of, but for any comparison to be useful, it should do
more than just match one APL operation with one J operation.
Chris
Phil Last
I disagree.
I do agree that a translator would be difficult. I'd raise that to
near impossible. But I'd have said also probably worthless. The
translation of idioms would have to incorporate all possible such in
both dialects. Might as well translate into C# or COBOL.
Surely the only real purpose of such a thing would be pedagogical and
I'd have thought a transliterator would be entirely sufficient for
that.
It would then be a matter of learning, within the target dialect, how
to reorganise the transliterated code into the idioms of that dialect.
Phil
Björn Helgason, j-programming
J and vice versa.
You will have to think about a few aspects to what APL you are looking
at.
You will also have to think about some system settings like index
origin.
I guess that you will get a better map between SAPL symbols and J than
APL2 and J.
So you might want to have a similar mapping between SAPL and APL2
Nick
> M34 {times} {transpose} ({rotate}{shape}M34) {reshape} V3 / APL
With all due respect, no APLX, APL2, APL2000, or Dyalog user would
write this, in 2009.
M34 x[0] V3
A translator could handle that one quite nicely.
As I said, the APL code would be restricted. Possibly even restricted
to contrived examples.
Certainly wholesale translation of existing applications, if not
functions, is out. However, as Phil points out, as a learning tool, a
translator strikes me as a worthwhile exercise.
Roger Hui
>
> With all due respect, no APLX, APL2, APL2000, or Dyalog user would
> write this, in 2009.
>
> M34 x[0] V3
So now suppose f is a non-primitive scalar function. Can the
APLX, APL2, APL2000, or Dyalog user then write?
M34 f[0] V3
If the main purpose is pedagogical, a operation-to-operation
transliteration would not be all that useful because almost
immediately in a translation one would need to explain about
function rank, prefix agreement, etc.
Another example is $ vs. ⍴ . The monads are the same.
The dyads are that x⍴y is x$,y , with the further
explanation that x$y is (x,1↓⍴y)⍴y . You'd then
have to explain why J does it that way (working
with "items" with "atoms"). Moreover, you'd probably
want to explain that ⍬⍴(⍴y),1 is #y . And then
you'd want to explain the point of #y by text
such as the following:
http://www.jsoftware.com/papers/average.htm
Peter Keller
> Certainly wholesale translation of existing applications, if not
> functions, is out.
As a compiler guy, I think the blanket statment of APL can't be translated
into J is wrong. All programming languages can be translated into all
other programming languages, period. The only issue is whether or not
the constructed translation is the kind a human would have written.
If you'd like a translation to be human palatable, then much more work
in the form of parse tree pattern matching and rewriting must happen
after the the abstract syntax tree is built in order to recognize and
translate idiomatic expressions from APL into J.
As for long APL expressions that can collapse into simple J constructs,
designing a common intermediate representation of APL and J would be the
means by which the simplification of the underlying operations from APL
into J would arise.
Later,
-pete
Björn
It would probably be interesting to have a Rosetta Stone type of
examples written in APL2 and then the same example written in SAPL and
then in J,
Each example solving same or similar situation.
It might even be good to get set of APL idioms written out like that.
Who would write such a Rosetta Stone and who would want to read it is
another issue.
We could then have a Rosetta Stone for beginners and maybe another for
more experienced users.