> > > > It keeps tacit adverbial and conjunctional programming weak. > > > Refusing to use available tools does accomplish that. > > > > Did you mean explicit tools? > > Yes.
The subject of the post is tacit completeness and I said from the start that for most users it makes a little difference, if any, if the current tacit adverbial/conjunctional facilities are weak or not. Suggesting the use of explicit tools instead of tacit tools seems to be a tacit admission that the tacit tools currently available are weak. > > It has worked for me. > > For a constrained problem space, sure. But the language needs to cover > more bases than a single (albeit significant) problem space, not just > in implementation but in documentation. > I do not know what you mean by "a constrained problem space." What I do know is that people with knowledge of functional programming and first-class citizenship, with a just little more extra explanation of what I have already given, get it and become productive quickly, which is what really matters to me. > Would you accept my choice to include explicit tools for dealing with > some issues related to syntax and parsing (my 'abstract1' and > 'abstract2' implementations)? I would accept that as a tacit admission that the j903 tacit tools are weak. > > "That is easier said than done." I am afraid I could be waiting for your > > actual tacit anonymous fixed version of the conjunction INTEGRATE > > indefinitely. > > And I would not attempt that when INTEGRATE currently does not > function for the desired example. I am sorry to hear that apparently the old calculus primitives were removed before their replacements were ready for prime time. While you wait for someone to fix them you might like to brainstorm the problem of referring tacitly to the arguments of verbs and if you find a solution you could illustrate how it is done by implementing the simple example I entertained earlier in this thread; namely, x u rank v y <-> x u " (x v y) y I confess I have not expended time checking if the old/new tacit trains can help. Who knows? You might find something useful there. > (1) Yes, you have to indicate that that was just a very simple > illustration taken from the BQN's documentation. > > But, given that there's even simpler expressions which achieve the > same result, what was the value of that simple illustration? Are we > focusing on BQN here instead of J? > > (2) No, you do not have to indicate that that was just a very simple > illustration taken from the BQN's documentation. > > But, given that there's even simpler expressions which achieve the > same result, what was the value of that simple illustration? Are we > focusing on BQN here instead of J? One reason to move the discussion to the chat forum was to be able to entertain other array programming languages. Incidentally, on the BQN's website, you can find how its documentation explains the subject within its context. BQN is a relatively young array language and time will tell if it succeeds. Now, imagine that a group of verbs, u0, u1, ... , un (with n far larger than 3) have been produced by a tacit program (verb) and are available as a gerund, or linear representations, or a boxed list of verbs. Further, u0, ... , un are tacit fixed verbs made of (a few, or dozens, or hundreds, or ...) of primitives. Finally, one wants another tacit program to take those verbs as an argument and produce the tacit fixed verb u0@: ... @:un (or using caps if you prefer). Apparently, you could not imagine encountering this scenario. I did encounter it for the first time a very long time ago. As I said, I am a user with special needs. > What are you seeing that I am not seeing here? > I was playing with the DLL, without installing the full system, (9!:14)'' j903/j64/windows/release-a/commercial/ www.jsoftware.com/2021-12-16T15:20:38/clang-13-0-0/SLEEF=1 I do not think it matters, in this case, that it is not a full installation; but, who knows? What I see is J freezing for a few seconds before vanishing completely. _________________________________________________________________________________ On Tue, Dec 28, 2021 at 8:33 PM Raul Miller <[email protected]> wrote: > > On Tue, Dec 28, 2021 at 6:27 PM Jose Mario Quintana > <[email protected]> wrote: > > > > It keeps tacit adverbial and conjunctional programming weak. > > > Refusing to use available tools does accomplish that. > > > > Did you mean explicit tools? > > Yes. > > > > I took a look at that problem, basically, it's this: > > > ... > > > Once I had that, I think this explicit model would be straightforward > > > to convert to tacit form: > > > ... > > > > "That is easier said than done." I am afraid I could be waiting for your > > actual tacit anonymous fixed version of the conjunction INTEGRATE > > indefinitely. > > And I would not attempt that when INTEGRATE currently does not > function for the desired example. > > > > > Carefully ;) I have trained a few people over the years with hardly any > > > > difficulty. > > > > > > That's not actually an answer. > > > > It has worked for me. > > For a constrained problem space, sure. But the language needs to cover > more bases than a single (albeit significant) problem space, not just > in implementation but in documentation. > > A hard won lesson is that sometimes seemingly minor implementation > tweaks can make the job of documentation much easier. > > > > That implication is, I think, a sign of limited thinking, since you > > > could also use tacit entities for the heavy tasks, dipping into > > > > "That is easier said than done." I will keep waiting for your, just over > > the lightweight class, tacit anonymous fixed version of INTEGRATE which you > > might, or might not, be able to produce. > > Would you accept my choice to include explicit tools for dealing with > some issues related to syntax and parsing (my 'abstract1' and > 'abstract2' implementations)? > > > > > Do I really have to indicate that that was just a very simple > > > > illustration taken from the BQN's documentation? > > > > > > That's not an answer, either. > > > > No, that was a question. > > I do not see the relevance of the answer here. So let's try a couple takes: > > (1) Yes, you have to indicate that that was just a very simple > illustration taken from the BQN's documentation. > > But, given that there's even simpler expressions which achieve the > same result, what was the value of that simple illustration? Are we > focusing on BQN here instead of J? > > (2) No, you do not have to indicate that that was just a very simple > illustration taken from the BQN's documentation. > > But, given that there's even simpler expressions which achieve the > same result, what was the value of that simple illustration? Are we > focusing on BQN here instead of J? > > > > That said, this is an interesting topic. > > > > We agree! > > PS. I am still curious, what part of the j903 language would you advise to > > remove to avoid the following interpreter crash? > > > > J=. ((<@:((":0) ,&:< ]) , ])([.].))(`:6) > > CRASH=. 5!:1@<'J' > > I do not get an interpreter crash from that, nor do I get a crash from > CRASH`:6 but I do get a stack error from CRASH J > > What are you seeing that I am not seeing here? > > But, yes, I suppose that this does illustrate tacit recursion. And, I > had forgotten about Y combinator approaches. > > That said, I think that fixing the math/calculus implementation to > address the explicit INTEGRATE example would be more interesting. > > Thanks, > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
