> My stance here is that *any* tool set necessarily is limited (aka > "weak") outside of a limited range of targets. For example: > ...
Yes, I have known for many years that you feel very constricted when you are asked to use only tacit tools when entertaining a nontrivial programming exercise. There is really no need for you to emphasize it. > But you're probably also not tracking orbital debris. Are you tracking orbital debris with explicit J? > > I would accept that as a tacit admission that the j903 tacit tools are weak. > > Sure, and I also think that that's what makes them desirable. So, we agree! (That j903 tacit tools are weak.) > Actually, I was thinking of spending some time trying to debug and/or > rewrite that calculus library implementation. That said, I have not > yet gotten around to it. That would be a very nice thing for you to do. > At the moment, I can't think of any reason why I would want to > calculate the rank of a verb dynamically, rather than knowing what it > was ahead of time. Then you might like to think of another illustrating example that might interest you, if you can. > I can imagine encountering this scenario -- you are basically I am glad you can see it now. ________________________________________________________________________ On Wed, Dec 29, 2021 at 4:07 PM Raul Miller <[email protected]> wrote: > > On Wed, Dec 29, 2021 at 3:20 PM Jose Mario Quintana > <[email protected]> wrote: > > 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. > > My stance here is that *any* tool set necessarily is limited (aka > "weak") outside of a limited range of targets. For example: > > (*) Shovels are weak at chopping down trees. > > (*) Explicit programming is even weaker at chopping down trees. > > (*) These weaknesses can be alleviated by dipping into alternative tool sets. > > (*) Most people do not need to optimize their tool sets for the task > of chopping down trees. > > We should not expect that a single tool set should be sufficient for > all tasks, no matter how baroque that tool set turns out to be -- this > even applies to something like > https://databricks.com/session_na21/redis-apache-spark-swiss-army-knife-meets-kitchen-sink > > > > > 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. > > Well, for example, I suspect that your problem space does not require > that your users personally chop down trees. > > I could be wrong about that, of course. > > But you're probably also not tracking orbital debris. > > For example. > > Anyways: all problem spaces are specialized. (Arguably, politics might > be declared to be an exception -- but I only say that because I rarely > understand what any of that crowd are talking about.) > > > > 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. > > Sure, and I also think that that's what makes them desirable. > > > > > "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 > > Actually, I was thinking of spending some time trying to debug and/or > rewrite that calculus library implementation. That said, I have not > yet gotten around to it. > > That said, referring tacitly to arguments of verbs is a solved problem > which means that the real problem here is the slightly different > problem of referring to arguments of *other* verbs. That's also a > solved problem (it's what we use names for), but as I understand it > you're looking for a weaker solution to that problem. > > > I confess I have not expended time checking if the old/new tacit trains can > > help. Who knows? You might find something useful there. > > At the moment, I can't think of any reason why I would want to > calculate the rank of a verb dynamically, rather than knowing what it > was ahead of time. > > > 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. > > I can imagine encountering this scenario -- you are basically > describing the semantic operation of a compiler or interpreter for a > programming language. > > This is actually a fairly popular problem, perhaps too popular -- see > https://devskiller.com/how-many-programming-languages/ -- but my > tastes here in recent years have been leaning towards a focus on > systems which connect to outside mechanisms (as opposed to pure > computation). Maybe someday I would circle back and focus on this kind > of task. But just as a warning: it's an open ended problem space, > because of resource constraints and because of conflicts between the > limits we have on the complexities of our abstractions and the > infinities modeled by those abstractions. > > > > 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. > > Oh... hmm... > > I routinely install the full system for my own use. When I want to > share something written in J with users who are not familiar with J, I > do lean towards a minimal deployment of J. But in that context I also > like using tools which monitor activity on the external interfaces. > Here, I lean towards working in linux (because of its strace tool -- > other OSes have similar tools, though -- tools which are not as weak, > but that makes them more difficult to use). > > Anyways, ... stack full problems are tough problems (because of its OS > and compiler specific character, and because it's a resource > management problem in a weakly specified but necessary and somewhat > variable kind of context). I usually try to open bug reports when I > notice that kind of thing. I can't think of a better approach here. > > 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
