Hi all! It does not seem picky about the representation.
atomic =:[: 5!:1 < boxed =: [: 5!:2 < f=: +/ % # (atomic'f') `:6 +/ % # (boxed'f') `:6 +/ % # atomic'f' ┌─────────────────┐ │┌─┬─────────────┐│ ││3│┌───────┬─┬─┐││ ││ ││┌─┬───┐│%│#│││ ││ │││/│┌─┐││ │ │││ ││ │││ ││+│││ │ │││ ││ │││ │└─┘││ │ │││ ││ ││└─┴───┘│ │ │││ ││ │└───────┴─┴─┘││ │└─┴─────────────┘│ └─────────────────┘ boxed'f' ┌─────┬─┬─┐ │┌─┬─┐│%│#│ ││+│/││ │ │ │└─┴─┘│ │ │ └─────┴─┴─┘ Cheers, Erling Hellenäs On 2017-10-25 18:21, Raul Miller wrote:
Yes, sort of, you are building atomic representations there. Note also that the box drawing characters are used to represent structure - you did not supply them as literals. But, take a look at t.c in the J engine source code to see an initial hint about what I am really talking about. Note also that this intermediate form is advantageous when supporting J's treatment of types. Types are necessary evils (which compilers tend to enshrine). Atomic representation is structurally similar to J's internal representation, though, and as it is an executable form (albeit one that needs a bit more interpretation than the internal representation), it also qualifies as an intermediate form. Converting from atomic representation to internal form is not very hard. (Too often, we rank unnecessary difficulty as being more important than usefulness. Perhaps this is because we like to follow our habits? Perhaps, also, a healthy sense of humor can be useful in coping with some of the resulting absurdities.) Thanks,
---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
