So... I've gotten part way into implementing this "less explicit atomic representation" concept, and I've run into to pain points -- routines I think I want which I think should already be implemented as a part of the direct definition implementation:
(1) A routine which extracts the reserved names referenced in a definition (from mnuvxy), and (2) A routine which extracts the monad/dyad boxed pair from the string representation of a definition. And, since I'm trying to build a J model, I of course want J implementations of these things. Before I dive too deep into this (I'll need to build a mini recursive descent parser as the basis for both of these)... do these j models exist already? Thanks, -- Raul On Tue, Oct 27, 2020 at 11:02 PM Raul Miller <[email protected]> wrote: > > Hmm... actually, this might mean something new -- this approach > suggests delving into the atomic rep, finding the explicit definitions > and converting them to dd. > > But that implies a less explicit ar which can directly represent a > direct definition. So, for example, making a '{{' token which has a > modifier indicating type (for example )a or )v or whatever), followed > by the direct definition text. Probably followed by an inert '}}' > token to make the ddrep implementation simpler... > > I would definitely want Eric to weigh in on a design change that hits > the system this deeply. > > Thanks, > > -- > Raul > > > > On Tue, Oct 27, 2020 at 10:44 PM Raul Miller <[email protected]> wrote: > > > > The lrep code does look a bit complicated. > > > > Probably the right place to start here would be to take the j model > > for lrep (at https://www.jsoftware.com/ioj/iojRep.htm) and build a j > > model for ddrep. > > > > I'll see if I can figure that out, but I don't know how long it'll > > take me to digest the issues. > > > > Thanks, > > > > -- > > Raul > > > > > > On Mon, Oct 26, 2020 at 10:36 PM Henry Rich <[email protected]> wrote: > > > > > > 2. I agree completely, and was planning to add this at some point after > > > DD has been finalized. > > > > > > If you want to get into modifying the JE, talk to Eric. Representations > > > are something I don't know very well - all I know is summarized in the > > > comments I have added - so we would be on equal footing. > > > > > > Henry Rich > > > > > > On 10/26/2020 9:05 PM, Raul Miller wrote: > > > > There are two things I would like to see for direct definition which > > > > are not currently implemented. I do not know if these have any > > > > roadblocks.( If they do have roadblocks, I would like to understand > > > > these blocking issues.) > > > > > > > > [1] Syntax highlighting. Currently, jqt uses a different color for > > > > {{ than for }} in multiline direct definitions. (jhs does not have > > > > this issue.) > > > > > > > > [2] Representation. I would very much like a variant on 5!:5 which > > > > produces a direct definition form which is analogous to linear > > > > representation except that it uses direct definition rather than > > > > explicit definition. (Name use conflicts could be handled by replacing > > > > n=. with 'n'=. and replacing other uses of n with ('n'~), and of > > > > course the same for other reserved names.) > > > > > > > > My primary use of this representation would be in J's default display > > > > (9!:3). > > > > > > > > If you think I should tackle these myself, I guess I can try (though I > > > > suspect I would goof up on my first attempt, and I do not know where > > > > jqt's syntax highlighting code is located). > > > > > > > > Thanks, > > > > > > > > > > > > > -- > > > This email has been checked for viruses by AVG. > > > https://www.avg.com > > > > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
