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
