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
