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

Reply via email to