Thanks for the reference. By my analysis, the beta-o parser would not
be any faster than it is if it had to verify the types of its arguments.
Your last point is absolutely right, and yet I want to ignore it.
Experienced J programmers have learned ways to avoid sentences that do
little work. Programmers new to J write what I call JTRAN: FORTRAN code
translated to J, with lots of scalar arithmetic. With a little
experience they will write better J, but I don't want to lose them
before they get the experience. I am trying to make the parser execute
JTRAN efficiently.
And, most of us lapse into JTRAN occasionally. (maybe not Roger)
Henry Rich
On 8/28/2021 11:37 PM, Elijah Stone wrote:
On Sat, 28 Aug 2021, Henry Rich wrote:
Large improvement would require heroic intervention: parsing &
caching sentences on the fly & watching assignments to make sure the
cached parse is valid. I would rather avoid that.
The technique has been implemented, to great effect -
http://www.softwarepreservation.org/projects/apl/Papers/DYNAMICINCREMENTAL
That implementation placed the invalidation in the parsed (and
compiled) sentence itself, rather than invalidating existing sentences
on assignment, which simplified matters; before a sentence is
executed, the inferred nameclasses of its referents are verified.
This is much simpler and easier to get right, and retains similar
performance (especially with modern branch predictors).
That being said, if the parser is a bottleneck for some code, then it
is likely doing something wrong and should perhaps not be encouraged :)
-E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
