4 ms·

Are you familiar at all with J? I've done some of the labs, and I'm getting fascinated with it. J and K are closely related, I'm wondering if someone more famil

Are you familiar at all with J? I've done some of the labs, and I'm getting fascinated with it. J and K are closely related, I'm wondering if someone more familiar with both could compare them.

beagle3 17y ago
(sorry for taking so long to reply) Yes, I'm familiar with J, and it is indeed closely related to K -- J was inspired, and in many ways evolved from A - an APL interpreter written by Arthur Whitney in one afternoon (see http://www.nsl.com/papers/origins.htm http://www.nsl.com/papers/origins.htm for more details). J tries to be complete and nice in the mathematical sense, e.g. having forks and trains, and functional inverses, as part of the language. K tries to be the simple practical language, rather than the philosophically consistent one: e.g. like APL and J, it is left-of-right long-right-scope, meaning 1+2+3+4+5 parses 1+(2+(3+(4+5))). However, the fold/over operator associates left - thus, +/ 1 2 3 4 5 actually computes (((1+2)+3)+4)+5 which seems inconsistent but is much more useful in practice. K (conceptually) has 3 data classes: atom (int, float, char, symbol), list (data indexed by sequential integers) and dict (data indexed by data -- an associative array); Everything else is an implementation detail (and these matter -- they make K blindingly fast -- but you can ignore them when trying to grok k). Multidimensional arrays are implemented as "list-of-lists" or "list-of-lists-of-lists ...." etc. (thus no "boxing" is needed). All list/dict access is done by indexing. Compress/expand are replaced by the "where" function which converts a list of booleans to their indices -- e.g. to zero all elements less than 3 you can do: x[where x<3]:0 / use : for assignment K has a much simpler base (which is surprisingly sufficient in practice), and the symbols make more sense to me. YMMV
- silentbicycle 17y ago
  Thanks, that's helpful. J and K do some sort of cache-friendly dataflow analysis (not just lazy evaluation), yes? I've seen that draft J interpreter before - It crashes immediately now, but I spent most of a Saturday morning with GDB picking it apart. That convinced me there's deep ideas there, not just a brainfuck-ish obfuscated thing.
  - beagle3 17y ago
    Actually, they don't. They just have cache-friendly primitives, and a compact interpreter that mostly sits within the i-cache of modern processors. It makes a world of a difference -- staying in the i-cache and doing mostly sequential access is easily 10 times faster than random, non-i-cache-friendly access.
    - silentbicycle 17y ago
      Again, thanks.

Are you familiar at all with J? I've done some of the labs, and I'm getting fascinated with it. J and K are closely related, I'm wondering if someone more familiar with both could compare them.

beagle3 17y ago

(sorry for taking so long to reply) Yes, I'm familiar with J, and it is indeed closely related to K -- J was inspired, and in many ways evolved from A - an APL interpreter written by Arthur Whitney in one afternoon (see http://www.nsl.com/papers/origins.htm http://www.nsl.com/papers/origins.htm for more details). J tries to be complete and nice in the mathematical sense, e.g. having forks and trains, and functional inverses, as part of the language. K tries to be the simple practical language, rather than the philosophically consistent one: e.g. like APL and J, it is left-of-right long-right-scope, meaning 1+2+3+4+5 parses 1+(2+(3+(4+5))). However, the fold/over operator associates left - thus, +/ 1 2 3 4 5 actually computes (((1+2)+3)+4)+5 which seems inconsistent but is much more useful in practice. K (conceptually) has 3 data classes: atom (int, float, char, symbol), list (data indexed by sequential integers) and dict (data indexed by data -- an associative array); Everything else is an implementation detail (and these matter -- they make K blindingly fast -- but you can ignore them when trying to grok k). Multidimensional arrays are implemented as "list-of-lists" or "list-of-lists-of-lists ...." etc. (thus no "boxing" is needed). All list/dict access is done by indexing. Compress/expand are replaced by the "where" function which converts a list of booleans to their indices -- e.g. to zero all elements less than 3 you can do: x[where x<3]:0 / use : for assignment K has a much simpler base (which is surprisingly sufficient in practice), and the symbols make more sense to me. YMMV

silentbicycle 17y ago
Thanks, that's helpful. J and K do some sort of cache-friendly dataflow analysis (not just lazy evaluation), yes? I've seen that draft J interpreter before - It crashes immediately now, but I spent most of a Saturday morning with GDB picking it apart. That convinced me there's deep ideas there, not just a brainfuck-ish obfuscated thing.
- beagle3 17y ago
  Actually, they don't. They just have cache-friendly primitives, and a compact interpreter that mostly sits within the i-cache of modern processors. It makes a world of a difference -- staying in the i-cache and doing mostly sequential access is easily 10 times faster than random, non-i-cache-friendly access.
  - silentbicycle 17y ago
    Again, thanks.