If you're still looking for things of this type, I have added my attempt at a formal parser for J grammar here: http://www.jsoftware.com/jwiki/MarshallLochbaum/Formal%20Parser It assumes that conjunctions and adverbs return verbs, so it's by no means always correct. However, due to the dynamic nature of J, full correctness is not possible without actual evaluation (we can always imagine a Turing-confusing computation passed as the left operand of : ).
Marshall On Sat, Jul 21, 2012 at 04:45:05AM +0100, Ian Clark wrote: > I accept what you are saying, and these are interesting points to > discuss. But they take me outside my current focus. Viz the question I > touched on in another thread: to take an explicit definition like: 4 : > 'x foo y' (where foo is an arbitrary tacit definition) and distribute > the x's and y's throughout the nested structure of foo. > > To take an example for the benefit of pragmatists trying to follow > this thread, I'm not asking for a whole BNF grammar but a simple > pragmatic set of transformation rules to convert, say: > 4 : 'x (a b c d) y' > into, say: > 4 : 'x a ((b y) c (d y))' > which I loosely called "multiplying out". > > It's not an arid theoretical problem. IMO it's the problem every > novice has to solve when trying to understand published samples of > tacit code. > > A lot of people, I find, have had independent stabs at this problem in > its multifarious forms, with loads of overlap, and I thought I'd build > a roadmap to the relevant pages in jwiki. But every approach I've come > across so far, including ones I've experimented with myself, ask J to > execute, in whole or part, the literal string: > 'x foo y' > for example: > 'x (a (b c d)) y' > in order to return either nouns or verbs. > > Is it really necessary to do that, for a 95% good-enough algorithm? > I'm not convinced. Not yet. But even if it turns out it is, I still > hope to sidestep the resource issues of handling substrings of foo > like: > '(i. 10#10)' > which gives limit error when executed, even when J is only being asked > to return foo as a tacit verb. > > As you so rightly say, papers in "Logic & Foundations", which I take > to include the formal proof literature, seldom consider resource > limitations. The question asked is: will the Turing Machine ever stop, > not when will it stop. But I suspect a 95% good-enough algorithm won't > become 100%, or even 96%, by expending much effort in this direction. > To my mind, a good-enough algorithm knows when to cop-out. > > > On Fri, Jul 20, 2012 at 9:30 PM, Raul Miller <[email protected]> wrote: > > On Fri, Jul 20, 2012 at 4:02 PM, Ian Clark <[email protected]> wrote: > >> Thanks, Raul. > >>>> 2. If baa is not a verb, how can I determine its type? > >>>> -short of actually assigning it to a local name: baa=. (...) and > >>>> calling 4!:0<'baa' ? > >>> > >>> What's wrong with that? > >> > >> What indeed? -- for the overwhelming majority of cases. If it turns > >> into an impossibly large noun, then just too bad. > > > > In this context, you are dealing with a representation of some element > > which must already exist. So "impossibly large" probably implies a > > bug. > > > > Meanwhile, the formal proof systems that I have looked at routinely > > ignore resource limits in their proofs. > > > >> I was trying to get right away from physically constructing (baa) each > >> time. My original approach had me doing just that, covering each verb > >> I found, running the tooled-up expression with test data and looking > >> to see if each (baa) was called monadically or dyadically, and with > >> what argument(s). If the algorithm runs to completion in reasonable > >> time, it's cast-iron. > >> > >> But, trained as an algebraist, I wondered if a useful subset of J > >> syntax (without copulas, and confined to verb trains) could be reduced > >> to a formal axiomatic system and handled by substitution rules: like a > >> semigroup presentation. > >> > >> At the time I guessed not - and your answer to my question 3 > >> reinforces that view: that J is "implementation defined" (like every > >> other programming language I know, with the possible exception of > >> Prolog) and therefore not (in the general case) amenable to algebraic > >> manipulation... > >> http://www.jsoftware.com/jwiki/Guides/Language%20FAQ/J%20BNF > >> more-or-less says as much. > > > > The issue here, from my point of view, is completeness. J's tools are > > implemented in J, so J needs some open ended features or it could not > > support J. > > > > If you do not care about supporting such "recursive toolbuilding", you > > can draw the line wherever you want and work with a subset which you > > support and declare the rest as "out of scope". > > > > For example, if I wanted to implement some BNF version of J, I would > > pick a single result type to support, for each built in adverb and > > conjunction (probably verb for : and noun for `) and ignore the other > > possibilities. This would prevent me from even having to consider > > explicit adverbs and conjunctions, which makes BNF easy (though I > > would still need to check name class when dealing with names). > > > > -- > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
