User talk:Raul Miller

From J Wiki
Jump to navigation Jump to search

Igor Zhuravlov

Igor Zhuravlov wrote the quoted material here, presumably in response to my comments on User:Igor_Zhuravlov/Data_teleport (which he has since deleted). And, since I didn't have any other content here, I'm just leaving it here (with some comments at the end), for now. 

 Variable copulas aren't allowed in tacit expressions. So, if some value has been derived in tacit expression, the only way to transfer it to another part of this expression (or, in general, of the whole program) is to pass it from one verb to another. E.g. a definition:
    expr=: (a0 b0 a1) c (a1 b1 a2)
 encodes an execution tree:
       c
      / \
    b0   b1
    / \   / \
  a0  a1 a1  a2
 If (x a1 y) is expensive to evaluate then its result once produced in one branch should be passed to another one (from right to left branch here, I guess). One may write something like:
    expr=: (a0 b0 (3 : 'val')) c (((3 : 'val=: a1 y') : (4 : 'val=: x a1 y')) b1 a2)
 But it's polluting the global namespace. One way to work it out is to use an extended fork:
    expr=. a0`b0`a1`c`b1`a2 fork3
 with execution tree:
        c
       / \
      b0  b1
     / \ / \
    a0  a1  a2
 An another way proposed here is to use a data teleport (say, defined under primitive t.):
    expr=: (a0 b0 t.@0) c ((0 t. a1) b1 a2)

The sentence "Variable copulas aren't allowed in tacit expressions" is ... inadequate, in my opinion.

A "Variable copula" refers to something like yyy=: expression. And, tacit expressions do not explicitly refer to their arguments.

However, tacit expressions do not exclude the use of words which have explicit definitions, so we have some obvious escapes from this claim. But there's another way, also, which is that if we're working with character data, we can write that data to a file and read it back in elsewhere, as a way of persisting the information.

But, also, we have other os interfaces (such as calling external procedures) which can achieve similar ends, if we wanted to bother with that.

So... while there is some truth and relevance in what Igor has laid out here, it's not the whole story.

With that in mind, here's an implementation for data teleport 

teleport=:3 :0
  ".'data',(":y),'_teleport_'
:
  ('data',(":x),'_teleport_')=: y
)

Example use: 

   0 teleport i.3 3
0 1 2
3 4 5
6 7 8
   teleport 0
0 1 2
3 4 5
6 7 8


I can't figure out whether this is grotesque or brilliant.

After seeing the original point, I came up with the following. It's very similar to yours but I define two adverbs instead, hopefully to better integrate into tacit expressions. 

   in=: adverb def 'y [ (m,''_inout_'')=: y'
   out=: adverb def '3 : (m,''_inout_'')'

   (+/ , # , +/ % #)"1 i.3 11
 55 11  5
176 11 16
297 11 27

   ('sum'out , 'count'out , 'sum'in@(+/) % 'count'in@#)"1 i.3 11
 55 11  5
176 11 16
297 11 27

Kirk Iverson (talk) 03:49, 11 October 2019 (UTC)

Raul and Kirk, thank you for comments. Now I see this simple idea can be easily implemented by plain J, so there is no need to touch the interpreter. BTW, I have no idea why my comment was deleted and why it's first version is so reduced. Raul, you've restored my comment in full and correct form, thank you!

--Igor Zhuravlov (talk) 04:29, 11 October 2019 (UTC)

If you are referring to my edit history here - I tried using blockquote but that removes some wiki formatting. So I fiddled with your text for a while before I figured out how to mark it off as quoted and still retain the formatting. This means that the edit history looks... garbled... --Raul Miller (talk) 16:14, 11 October 2019 (UTC)

Addons/math/mt/MATRIX

Raul,

I don't agree with your revision https://code.jsoftware.com/mediawiki/index.php?title=Addons/math/mt/MATRIX&diff=39512&oldid=34025 , since mt should be loaded only by: 

   load 'math/mt'

or by: 

   require 'math/mt'

that is, as the whole from the top entry point. Loading just a part e.g. 

   require 'math/mt/trf'

in the fresh session will make it broken due to missing dependencies: global nouns, system definitions, utilities and low-level parts. This partial loading has sense only within the limited circumstances e.g. in an addon development workflow after the whole addon has already been loaded.

I guess I agree with your perspective here. Thanks. --Raul Miller (talk)

Modifier Trains semantics

Hi Raul,

I’d like to modify the MT intro text to be the same thing I put at the bottom of the Forks page where modifier trains are introduced: "[t]he table below lists the valid sequences that can be used directly (that is, without parentheses) within modifier trains, along with the interpretation for each."

E.g. the reason NVN is included in the table is because the NVN subsequence in the modifier train NVNCA is evaluated as if it were parenthesized. Similarly for VV, VN, VVV, NVV.

Also, the glossary’s definition of ”train” is "[a] sequence of words that when executed produces a non-noun result, typically a verb." Considering this, we can see that there is no proper way to introduce the table entries in terms of trains, because the entries like VN and NVN are not trains, since they produce a noun result. Therefore we should also change the "train" column heading in the table to "sequence".

Thoughts / objections?

Btw, I appreciate the colors you’ve added to the table, and Bob relayed the same as well. Cameron Chandoke (talk)

I think we should first consider that the glossary entry is incomplete and, thus, misleading - it's a summary which leaves out important details. One useful approach might be to provide a link from the glossary to a reference page such as https://www.jsoftware.com/help/dictionary/dictf.htm#. But we should also probably add to the entry to distinguish trains from examples like 1 :'u'. Perhaps we should emphasize that a train retains all of its components where evaluation replaces its components with a result (though Quines present an obscure corner case where this rule of thumb is inadequate)?
One potential problem I see here is that if we generalize "train" to include meta-evaluation (operators which when evaluated produce a non-noun result) then we've obscured the meaning of existing documentation which uses the term "train".
More specifically... VV, and NVV are trains. Meanwhile, NVN is not a train, but could be part of a train (for example: NVNVV). As for NVNCA, that's a mix - in that example, NVN gets evaluated to a noun producing an NCA trident (which is a train).
I've been watching you work through some of those examples, and it seems like an interesting topic. But I am starting to think that this isn't something which we can really separate from an understanding of how J's parser works.
I hope this helps... --Raul Miller (talk) 13:48, 4 October 2023 (UTC)
Right; regarding meta-evaluation, that’s fair. I really only meant to emphasize that noun phrases are not trains, which we agree on. Yes, I had the same thought about specifically excluding 1 :'u' and {{...}} in the "train" definition.
Regarding the "...retains all its components..." part, that seems like a matter of arbitrary semantics and therefore not the best revision. 1.) (AAVCCNCV) and 2.) (VVV) don’t really retain their parts any more than 3.) +/@:* does; 1.) produces a derived conjunction, 2.) a derived verb, and 3.) also a derived verb. So in short, each produces a single derived entity. Or if we’re talking about the ability to look at the derived entity and break it into its parts, 5!:1 and friends allow this in all three cases, so here too there is no distinction. Unless I missed some relevant distinction in J’s evaluation model.
Anyway, having said this, I’d like to ask specifically whether you’d object to:
  1. changing the "Train" column to something more general like "Sequence", on the grounds that the column includes noun phrases
  2. revising the table description to say “the table below lists the sequences that can be used unparenthesized within tacit modifiers" rather than “below is a table of all evaluative sequences allowable in a J sentence” or somesuch

... and if so, what specific objections. I didn’t want to immediately overwrite your edit without considering your feedback on my proposed change. Cameron Chandoke (talk)

Your point about +/@:* is a good one. (Here, the evaluation of the modifier does indeed retain the original components for its display form.)
However, I would be careful about excluding {{...}} from trains, because that's just a blank slate which eventually resolves to one of N V A or C, and because internally, {{...}} is a single token in the actual implementation of the J parser. (I've been meaning to write an essay on this, with an implementation model. It's not a trivial concept.)
As for replacing Train column header with Sequence - I think that makes sense. Though if we did that, I think for relevance sake we should also introduce a new Train column header whose values are verb / modifier / no. (And I think this would eliminate the need for a sentence which explains the distinction between trains and sequences.) --Raul Miller (talk) 12:45, 5 October 2023 (UTC)
Ok, sure, about the curly braces.
There should be no need for a new column, I think, as there is no relevance/significance as to which table sequences are trains in the first place—only that these sequences can be used w/o parens within MT’s. (We’d introduce MT’s by saying they’re word sequences that produce modifiers.)
In the context of modifier trains, “train” refers to the entire sequence that derives a tacit modifier; its presence in the phrase “modifier train” does not reflect a connection to individual subsequences. So, not appropriate to relate it to them. That’s my thinking so far anyway.
What I’d ideally prefer though is to not even document that e.g. NVN—or VVV for that matter—can be used without parens within MT’s, since it hardly affords extra convenience, and results in the terrible grouping complications I brought up in the discussion page. So the suggestion here is that we amend the table to include only entries that derive modifiers, and remove the others.
Clearly, no one reading a page on tacit modifiers needs to read that VN evaluates to a noun, or that VVV evaluates to a verb/fork, within an MT; I find it really weird and confusing for them to be there at all. I would leave the user to parenthesize verb/noun phrases. I mean let’s consider that you already have to parenthesize noun phrases except when it’s leftmost in the compound train.

--Cameron Chandoke (talk) 04:06, 6 October 2023 (UTC)

As I understand it, a train is a hook or a fork and necessarily includes longer sequences which form hooks or forks. I think "invisible modifier" describes the same concept, but is more wordy (and is grammatically different, so requires a different english sentence structure when used). As such, I don't agree that distinguishing between trains and other sorts of sequences provides no information. But I can add the column if you do not feel comfortable doing that.
Meanwhile, my understanding is that re-iterating basic issues helps orient new users. I think that this is why, in NuVoc, we repeat some basic information in many places.
Finally, I don't think it's appropriate to structure the documentation based on hypothetical changes to the language. --Raul Miller (talk) 06:30, 6 October 2023 (UTC)
Of course, the distinction does convey information. It’s just that to me, at present, this information seems tangential/unrelated to modifier trains themselves. Yes, it would be more natural for you to add it if you like.
Sure, I concede the idea about repetition of basic concepts.
That’s fair, regarding restructuring the documentation. (For clarity, I was advocating for the restructuring independent of whether the language changes.)

—Cameron Chandoke (talk) 22:03, 6 October 2023 (UTC)

Well, our wishes have been granted. Here’s a copy of the original dictionary section on trains which I found from this mailing list entry. Aaand it’s exactly as I imagined it: same as the current one, but with a minimally formatted version of the sequence table. Hahaha of course.

Here’s the corresponding page on Lev/Dex/Ident. The provided examples also don’t hint at any usefulness…

Reminds me of this moment from Zootopia.

You may be interested to look at the original parsing page as well.

This is also available through the Wayback Machine site; there one can see how all the primitives used to be displayed in columns the side.

I also put this on my talk page to preserve surrounding context. --Cameron Chandoke (talk) 01:26, 17 October 2023 (UTC)

When you mentioned rules 6 and 7 of the parse table in the MT page, it seems like this should be 5 and 6 (fork and hook)? They are numbered from 0 in the JforC chapter and J’s dictionary; 7 is the assignment one based on the 0-based numbering scheme. Will change for now; revert if needed.

Also, I’ve seen nonexistent pages linked to before but am unfamiliar with the idea/purpose. Does it make sense to link to either the dictionary or JforC pages until the new page is created?

Ah, good finds.
And, yes, conceptually at least I think it's fine to link back to the www.jsoftware.com instance of the dictionary. (I prefer it in some ways over nuvoc, though nuvoc has been improving.) That said, in this particular case, note that we have Vocabulary/Parsing which could use some attention but does exist. --Raul Miller (talk) 05:31, 17 October 2023 (UTC)
Oh, I see, you had meant to link to that page. Huh, I wasn’t aware that we already had a table with the modifier trident rule I had just discovered from the old dictionary link. Well that’s convenient.
Good call about the parse table; it has enlightened me greatly. It does of course explain every one of the grouping cases I had showcased. The behavior is significantly more complex than I ever would’ve guessed, due to having to keep track of the top 4 stack words at all times. Crazy. --Cameron Chandoke (talk) 09:23, 17 October 2023 (UTC)
As I understand it, the original purpose of the design was to support or work towards supporting combinators using infix notation. The design of gerunds is also relevant here. A problem though is that combinators are complex to think about and lack applications. But that hasn't kept people from being interested in them. --Raul Miller (talk) 12:39, 17 October 2023 (UTC)

So, upon inspection, I’m totally confused by the reasoning behind the * and † distinctions:

  1. * : description says “… combination of a conjunction with a single argument on its right, forming an adverb.“
    1. * is given to tridents, where the C has an operand on each side, not just a right operand.
    2. as a separate issue, * is given to tridents like CCN that form a conjunction, not an adverb.
    3. it seems like the reasoning is that the trident resolves from the right, 2 words at a time. So like, equating CCN to C(CN). But—assuming that was the thought—it doesn’t evaluate this way; per the parse table, a train will always evaluate as a trident if possible since the fork and modifier trident rules are above the hook/bident one. Hence why the parens in A(CN) were necessary prior to the reintroduction of MT’s, else it gave a syntax error.
  2. † : what is the reasoning behind distinguishing “long left scope” (actually “extend verb/noun phrase as far leftward as possible”, a distinction that has relevance here) when there’s also a symmetric “extend verb/noun phrase as far rightward as possible” for all of the right-tine train-forming MT’s, e.g. AV, AAV, CVV? Seems arbitrary to distinguish one and not the other.

--Cameron Chandoke (talk) 09:23, 17 October 2023 (UTC)

Here, I think it's important to distinguish between a trident and a fork, and between the grammar used inside the trident and the grammar of the trident itself. Some tridents result in forks but others do not. And the trident (and bident) parsing rules are meant to represent deferred cases for the monad/dyad rules (for verbs) and adverb/conjunction rules (for adverbs and conjunctions).
So, for example, (sticking with the convention where C represents a conjunction, A represents an adverb, V represents a verb and N represents a noun) (C A) forms a conjunction, and (C C N) also forms a conjunction, and the (C C N) conjunction is equivalent to (C (C N))as the (C N) bident forms an adverb.
But, also, adverbs and conjunctions (modifiers) can take verbs as arguments. These typically construct new verbs, which would then take nouns as arguments.
Another thing to be aware of (and careful about) is that verbs have ambivalent syntax, while adverbs and conjunctions cannot have ambivalent syntax. In other words, 3-5 and -5 both use the verb - but there's two different definitions used in the underlying implementation (the two argument case has a definition and the one argument case has a definition).
Anyways, adverbs take their single argument on the left while the monadic verb case takes its single argument on the right. And this, combined with the need for modifiers to take verbs as arguments leads to the precedence rules.
Note also that J is basically an updated implementation of Sharp APL, and its syntax was designed to be largely consistent with APL's syntax (though, granted, trains were something new, and J did not implement the bracket indexing syntax of Sharp APL). --Raul Miller (talk) 12:39, 17 October 2023 (UTC)
Retrieved from "https://code.jsoftware.com/mediawiki/index.php?title=User_talk:Raul_Miller&oldid=46372"