Well.. technically, I do not want to generate a linear rep. I want to generate a direct definition rep.
Or, at least, that is my current thinking. But, also, the linear rep code does not do much of anything special for explicit definitions. It just rearranges the atomic representation of the code into a linear format. (Though it does seem to munge a literal matrix into a literal vector, so maybe I will be able to take advantage of that...) Anyways... I'm still working through the issues, and I expect I will have to change the details, but I have run into another problem, which is that the lrep model crashes J. Actually, it throws a domain error, because it seems to expect that the verb 'type' is defined as 3!:0 and that's not what the current definition is, But, replacing 'type' with 3!:0 in the definition of value at https://www.jsoftware.com/ioj/iojRep.htm crashes J for me when I try to use lrep. If that doesn't give you an easy test case, let me know and I can try narrowing down the cause of the crash. Though if you have any hunches, I would also like to hear them because that will likely help me isolate the offending code. For example: ex=: {{+/y}} lrep <'ex' 0 libj.dylib 0x0000000119f644a0 jtio14 + 14400 1 libj.dylib 0x0000000119edadaf jtindexofprehashed + 1247 2 libj.dylib 0x0000000119d9b45f on1cell + 159 3 libj.dylib 0x0000000119dad975 jtfolk1 + 181 4 libj.dylib 0x0000000119e03862 jtunquote + 514 5 libj.dylib 0x0000000119dad9b8 jtfolk1 + 248 6 libj.dylib 0x0000000119dad975 jtfolk1 + 181 7 libj.dylib 0x0000000119dad975 jtfolk1 + 181 8 libj.dylib 0x0000000119dad975 jtfolk1 + 181 9 libj.dylib 0x0000000119e03862 jtunquote + 514 10 libj.dylib 0x0000000119db0820 jtcasei12 + 208 11 libj.dylib 0x0000000119e03862 jtunquote + 514 12 libj.dylib 0x0000000119d9b498 on1cell + 216 13 libj.dylib 0x0000000119d9b498 on1cell + 216 14 libj.dylib 0x0000000119db09c3 jtcasei12 + 627 15 libj.dylib 0x0000000119e03862 jtunquote + 514 16 libj.dylib 0x0000000119db09c3 jtcasei12 + 627 17 libj.dylib 0x0000000119e03862 jtunquote + 514 18 libj.dylib 0x0000000119dcc949 jtevery + 569 19 libj.dylib 0x0000000119d9b498 on1cell + 216 20 libj.dylib 0x0000000119dad975 jtfolk1 + 181 21 libj.dylib 0x0000000119e03862 jtunquote + 514 22 libj.dylib 0x0000000119db09c3 jtcasei12 + 627 23 libj.dylib 0x0000000119e03862 jtunquote + 514 24 libj.dylib 0x0000000119db09c3 jtcasei12 + 627 25 libj.dylib 0x0000000119e03862 jtunquote + 514 26 libj.dylib 0x0000000119d9b498 on1cell + 216 27 libj.dylib 0x0000000119d9b498 on1cell + 216 28 libj.dylib 0x0000000119e03862 jtunquote + 514 29 libj.dylib 0x0000000119df63c6 jtparsea + 1846 30 libj.dylib 0x0000000119df5c72 jtparse + 66 31 libj.dylib 0x0000000119df93c5 jtimmex + 85 32 libj.dylib 0x0000000119de8e49 jdo + 265 33 libj.dylib 0x0000000119de9351 JDo + 97 Engine: j902/j64avx2/darwin Beta-i: commercial/2020-10-20T10:35:52 Library: 9.02.06 Qt IDE: 1.8.7/5.12.7(5.12.7) Platform: Darwin 64 Installer: J902 install InstallPath: /users/rauldmiller/applications/j902 Contact: www.jsoftware.com Thanks, -- Raul On Wed, Oct 28, 2020 at 9:35 PM Henry Rich <[email protected]> wrote: > > I feel that you are off in the weeds. But you are so seldom there, > maybe I just don't understand. > > AR is not a native JE rep. It's there for portability. Converting an AR > to LR is nothing you would ever see in the JE. Thus I think your work on > a J model is misdirected. > > Moreover, you will never feed it an AR of ((,'0');'{{'). {{ is a > spelling error. It will never get into the parser and will never be > part of a verb. > > Furthermore, {{ is not a noun. It is a control word. Its AR would be > (<'{{'). > > Nested DDs are represented as (9 : 'string'). [This is internal and > subject to change.] The LR for this is already converted to a DD: > > a =. 3 : 0 > b =. {{ x + y }} > b y > ) > 5!:5 <'a' > 3 : 0 > b =. {{ x + y }} > b y > ) > > Where the new LR class is needed is in the display of the outermost > definition. You want the LR of A to be > > {{ > b =. {{ x + y }} > b y > }} > > I think this is a fairly small change to the LR code. A deeper question > is whether the resulting string, when executed, will reproduce the > desired value. That is an issue to be resolved during the beta. > > Henry Rich > > > > > On 10/28/2020 6:54 PM, Raul Miller wrote: > > Right -- I was talking about the mechanism that would be used to do that. > > > > The linear representation code at > > https://www.jsoftware.com/ioj/iojRep.htm works by taking an atomic > > representation and converting it into a linear representation. > > > > In other words, the linear representation of {{+/y}} is 3 : '+/y' > > > > More specifically, to generate > > 3 : '+/y' > > > > that linear representation code starts from this data structure > > > > {{+/y}} arep > > +---------------------+ > > |+-+-----------------+| > > ||:|+-----+---------+|| > > || ||+-+-+|+-+-----+||| > > || |||0|3|||0|+ / y|||| > > || ||+-+-+|+-+-----+||| > > || |+-----+---------+|| > > |+-+-----------------+| > > +---------------------+ > > > > What I was saying is that I could use that same code, with relatively > > minor modifications, if I were to feed it something that looked like > > this: > > > > +-----------------------------+ > > |+-+-------------------------+| > > ||:|+------+---------+------+|| > > || ||+-+--+|+-+-----+|+-+--+||| > > || |||0|{{|||0|+ / y|||0|}}|||| > > || ||+-+--+|+-+-----+|+-+--+||| > > || |+------+---------+------+|| > > |+-+-------------------------+| > > +-----------------------------+ > > > > But this doesn't deal with the occasional need for decorators like )a > > -- that gets into deeper waters. > > > > That said, maybe as proof of concept I should start with an > > implementation which includes those decorators on multi-line > > definitions and leaves them off of single line definitions? (Since the > > decorators themselves currently require a newline to separate them > > from the first line of code). > > > > Note also that what I am saying means that this implementation would > > NOT deal with the improper use of bare reserved argument names in the > > resulting code, for single line definitions. But since that's a > > relatively minor problem, maybe it's the right approach? > > > > Thanks, > > > > > > -- > > Raul > > > > On Wed, Oct 28, 2020 at 8:46 AM Henry Rich <[email protected]> wrote: > >> You don't want to touch the internal representation (which is different > >> from AR). What is produced by {{ }} is just an explicit definition. > >> > >> What you want is a switch to display an explicit definition using {{ }} > >> rather than n : 0. That could be as simple as using {{)x }} . > >> > >> A different decision is whether you want to remember how a verb was > >> created, and display it in that form. > >> > >> Henry Rich > >> > >> On 10/27/2020 11:02 PM, Raul Miller 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, > >>> > >> > >> -- > >> 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 > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
