Hacker News Reader

Comment by jbclements | Hacker News Reader

From a PL standpoint:

1) APL clearly made good use of an extensive symbol set. Now that many languages support unicode, this is totally do-able.

2) APL is in love with overloading. It's not totally my cup of tea, but you could definitely fit this into many modern languages.

3) I see a whole lot of MATLAB in there.

4) Did... this article actually define any functions at all? Perhaps I missed this.

5) It looks you could easily implement APL as a DSL within an existing language with an extensible parser. Racket, for instance.

View on HN

5) It looks you could easily implement APL as a DSL within an existing language with an extensible parser. Racket, for instance.

I'm working on something along these lines, but not planning on keeping the APL/J-like syntax (the many meanings of juxtaposition makes parsing a line depend on the run time values attached to names). You can get more of the core idea of APL out of prop:procedure than out of extensible parsing.

I've been doing something similar as a gem to add J commands to Ruby: https://github.com/michaelfeathers/jop

The fluent interface is likely to win because I don't want to implement hook and fork.

Are dyads only done by putting the other operand in the string of J code? Or is there a nice way to apply a dyad to two Ruby arrays? (I wasn't sure from the Readme if this is already there or your second point in "future directions," and I'm pretty new to Ruby)

No real nice way. I'm not sure where I am going to go with this, I could use a string interpolation but I'm hesitating.

3) More correctly would be to say that MATLAB has a whole lot of APL. APL is one of the oldest languages, being developed in 50's.

5) You'll perhaps lose some power. Notation is important - check Ken Iverson's Turing lecture.

re. 4) Yes it did, about 1/3 in:

    ∇ R ← Average V

[1] R ← (+/V)÷(⍴V) ∇

Reply on news.ycombinator.com