Is the remark in parentheses just meant to make the previous statement more precise, as in "I'd like to have an APL dialect in Prolog; more precisely, I'd like to work in SWI-Prolog and implement something more like J"? Or is there some other distinction between APL/Prolog on the one hand and J/SWI-Prolog on the other hand that you are making?
Saw your comment on Reddit about this, am still confused by why you think this is a good idea. The integration of Prolog variables and backtracking is going to make a real mess of the array operations, don't you think, or is it going to be a total embedding? If it's a strict embedding, why not just have a J process and call it from SWI-Prolog?
Well, think of the IS operator
Z IS X + Y. That exists fine and works well.
X and Y can't be a variable only Z really can be. It can be annoying but that's standard Prolog.
So for the sake of discussion let's say we have
apl(Expression, Result).
Where Expression can't be a variable. If it fails to evaluate or has an error it will return false. If APL evaluates without error it will true true or the Result.
Prolog can be fast with list if using difference lists. But can be slow for some vector calculations. Using CHR/CLF one can do some mathematical calculations fast, but it runs out of memory fast for large dataset.
I might be wrong, but I figure it will be a nice experiment. My idea is to leave all things Logical and one of off type of code to Prolog and things that happen in groups to APL.
I don't think clpfd or chr are especially large hogs of memory. Have you run into issues there?
If you can write a smallish program that uses a subset of J (actually APL might be easier, since it is less likely to interfere with SWI's parser) I would be willing to try and figure out how to run it. Aim for 5-10 lines. Email me. I like the idea I'm just not totally convinced.
I feel like if I got better at J, my problems with it probably would be resolved. For instance, it feels to me like J is really bad at parsing (beyond regular languages anyway) and tree structures. But there are built-in verbs for these things, so I could be mistaken. I only threw a few months at it last year. And I kept being indecisive about APL and J. It didn't help that Aaron Hsu was such a passionate advocate for APL, and Roger Hui apparently now works for Dyalog and has tried to close the loop on a lot of the ways J improved on APL there.
My back-of-the-envelope sense, from writing a small amount of J and a fairly significant amount of Prolog, is that J is way better at solving the core of a certain class of problem, but you spend a lot more of your life converting the input into an internal representation you can use and back to a result a human might want to see. Prolog really likes a certain class of problem which is somewhat less general than J, but it makes up for that limitation somewhat by being amazing at parsing and having great internal representations of things. In most of the cases where I would want non-determinism in J, I would probably try to rework my problem so that I'm doing all the possibilities at once and then detecting which ones succeeded. If I had non-trivial calculations to do, I probably wouldn't use Prolog, but if I had to, I would certainly consider calling out to C or something. My day-to-day interests seem to coincide more with what Prolog does well than what J and APL do well.
Anyway, I think it might be a profitable area to explore. I was curious about Brachylog for similar reasons. https://github.com/JCumin/Brachylog
Anyway, I'm curious if you could show me what you are thinking. There must have been a smallish program you thought would work well with this combination. Can you share it?
