"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."
Is there any source documenting the internal representation for those of us who are C illiterate? Do you have any utilities to convert from atomic representation to internal representation and back? On Wed, Oct 25, 2017 at 12:21 PM, Raul Miller <[email protected]> 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, > > -- > Raul > > > On Wed, Oct 25, 2017 at 11:02 AM, Erling Hellenäs > <[email protected]> wrote: > > Hi all ! > > > > This post describes what I call the ascii representation. > > > > http://www.jsoftware.com/pipermail/programming/2017-October/049324.html > > > > An example: > > > > ((<('+';'/');'%';'#'))(`:6) 1 2 3 > > 2 > > > > ((<('+';'/');'%';'#')) > > ┌───────────┐ > > │┌─────┬─┬─┐│ > > ││┌─┬─┐│%│#││ > > │││+│/││ │ ││ > > ││└─┴─┘│ │ ││ > > │└─────┴─┴─┘│ > > └───────────┘ > > > > This is what Raul calls "J compiled to an intermediate form with some > data > > structures" ? > > > > Cheers, > > > > Erling Hellenäs > > > > > > > > Den 2017-10-25 kl. 13:38, skrev Raul Miller: > >> > >> I think you've introduced some false dichotomies here. > >> > >> First off, it's true that the J implementation is an interpreter, and > >> it does not compile J to native code. Instead, it compiles J to an > >> intermediate form which includes some ascii and some data structures. > >> The displayed form represents those data structures with more > >> characters (optionally: pure ascii). > >> > >> What Jose is doing here is manipulating data structures which J uses > >> to represent programs and data. In F# terms, this would be like "AST > >> Introspection" and "IL generation". (But, of course, J is not F#, and > >> discussions focussed on F# would be best left for other contexts -- > >> perhaps the chat forum, here?) > >> > >> Anyways, because the J interpreter compiles to a representation which > >> uses (compact) ascii to identify instructions, I think the answer to > >> your third question should be "no". Or, maybe "yes, but no". > >> > >> That said, maybe I can be not just pedantic but useful. I've been > >> working on understanding the mechanics of hg, and one approach > >> involves replacing adverbs definitions with adverb names. And, if we > >> consistently use a name for the (`:6) adverb, we can use that to > >> display the progress of gerund evaluation adverbs, as they trigger. > >> > >> In other words, starting with: > >> > >> ar=: 5!:1@:< > >> > >> a0=: `'' > >> a5=: `:6 > >> a1=: (@:[) ((<'&')`) a5 > >> a2=: (`(<(":0);_)) a5 > >> av=: ((<'a0')`) (`(<'a1')) (`(<'a2')) a5 > >> NB. Adverbing a monadic verb (adv) > >> echo 'First test' > >> assert 1 4 9 -: 1 2 3 *: av > >> > >> aw=: < @: ((0;1;0)&{::) NB. Fetching the atomic representation > >> a3=: (@:aw)av > >> a4=: "_ > >> a6=: (('a4' ; ] ; 'a3'"_) av) a5 > >> > >> hg=: `(;:'a6 a5') a5 > >> echo 'Second test' > >> assert 1 4 9 -: 1 2 3 ((<'*:') ; ]) hg > >> > >> we can replace the a5 definition with: > >> > >> glr=:3 :0"0 > >> t=. y 5!:0 > >> r=. 5!:5<'t' > >> ".'check=.',r > >> if. y-:5!:1<'check' do. r else. > >> 'NB. linear representation triggers J bug' > >> end. > >> ) > >> > >> gtyp=:3 :0"0 > >> t=. y 5!:0 > >> typ=. type't' > >> if. typ-:<'noun' do. > >> typ=.<(;typ),': ',datatype t > >> end. > >> ) > >> > >> a5=:1 :0 > >> echo (<@glr m),(gtyp m),:m > >> m`:6 > >> ) > >> > >> This displays each evaluated gerund as three rows. The first row is > >> (usually) the linear representation of the corresponding gerund > >> element. The second row is the type of the corresponding gerund > >> element, and the third row is the gerund itself. > >> > >> You can use the second row, along with the parsing specification > >> documented at http://www.jsoftware.com/help/dictionary/dicte.htm to > >> determine how the gerund is being interpreted. The first row shows you > >> some (hopefully helpful) details about what is being parsed. > >> > >> Note also that you will get this debugging output each time you use > >> this instrumented version of hg. This can be beneficial if you have > >> the time to digest what's being displayed but would be a huge > >> annoyance in other contexts. > >> > >> That said, describing the purpose of hg (and why one would want to use > >> hg instead of av) is eluding me at the moment. Maybe when I wake up > >> some more I would be better prepared to address this. > >> > >> Thanks, > >> > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
