I'm defining the term outdent as a line that is indented less than its previous
line.
So, because line 3 is outdented from 2, the rule is to close off the parent of
line 2 (ie. line 1). You always close off at least one parent, as a result of
an outdent, and must check if parents further up in the hierarchy also need to
be closed off based on whether it is outdented (or 'equaldented') from that
level.
If the line below is indented, then start a new parent tree with the current
line (ie. leave parenthesis open)
Anotherexample =: 0 : 0
l1
l2
l3
l4
l5
l6
l7
l8
l9
)
result
(l1
(l2
(l3
(l4)) NB. l3 closed
(l5
(l6)
(l7))) NB. l2 and l5 closed
(l8)) NB. l1 closed
(l9) NB. sibling to l1
the result for the simpler clean test case:
test =: 0 : 0
html
head
body
p stuff
p div='adiv'
more stuff
table
tr
td 1
td 2
p last stuff
)
(html
(head)
(body
(p stuff)
(p div='adiv'
(more stuff ))
(table
(tr
(td 1)
(td 2)))
(p last stuff)))
>>It doesn't match a sample, but a sample is not a spec.
>>If you can describe what rule I've violated, that rule could become a
>>part of the spec.
There's 2 "mistakes" in your solution. 1. body is treated as a child of head
instead of a sibbling. 2. A less important difference is that the tr group has
an un-needed extra level of depth.
----- Original Message ----
From: Raul Miller <[EMAIL PROTECTED]>
To: Programming forum <[email protected]>
Sent: Wednesday, April 4, 2007 9:33:17 AM
Subject: Re: [Jprogramming] Parsing Pythonish
On 4/3/07, Pascal Jasmin <[EMAIL PROTECTED]> wrote:
> for your example
> example=:0 :0
> line 1
> line 2
> line 3
> line 4
> line 5
> )
>
> I think the result is like lisp:
> (1
> (2))
> (3
> (4))
> (5)
>
> I think the rule is if the line below is indented, you leave the current
> line's
> parenthesis open. If the line below is outdented, then you add an extra
> parentheses to close off your parent. If that line is outdented futher than
> your immediate parent, then you close off that parent too and check one level
> up.
> That's what I'm looking for anyway. Is the problem easier by starting with S
> expressions (above parenthesized form without white space)?
If I understand your description, wouldn't that example parse as
(1
(2)
(3
(4)
(5)))
?
For example, you have described closing off 2 for 3, but you have
not described closing off 1 for 3.
Do I have this right?
> I'm having a hard time understanding your solution.
>
>
> blocks=: [: +/\ ' ' ~: {."1
> nest2=: <@{.`({. <@,&< (blocks $:/. ])@(}."[EMAIL PROTECTED]))@.({. <&('
> '&[EMAIL PROTECTED]) {:)
> nest2 [;._2 test
>
> In the rhs to agenda, '({. <&(' '&[EMAIL PROTECTED]) {:)' I don't get why
> comparing the head
> to the tail is relevant.
That's for degenerate cases -- to avoid infinite loops for cases like:
,.'this is a test'
> Its very impressive that you can keep track of what and where the dyads are in
> that sentence, but that got me lost, even if comparing head and tail is
> appropriate. Studying your code did make me understand an important
> application of dyad &, but its overall too much of a stretch for me to fully
> appreciate.
One thing I do, if I'm having trouble understanding my code (for example,
when I've written code which is throwing errors) is break out sub verbs
from a larger verb phrase and evaluate those sub-verbs against some
relevant chunk of data.
In other words, if you understand the wrapper verbs you should be able
to supply example nouns to the inner verbs. Alternatively, if you do not
understand the wrapper verbs and want to see what gets passed to the
inner verbs you can use either some really simple verb (<@] or the
like), or you can "process" arguments using something like ][smoutput
Or, if you prefer with ][ [:smoutput bind '-----' smoutput
(changing the line at the end to something else,, like maybe '+++++' if
you need to see several different points in the execution in the same context.)
> it doesn't quite match the spec:
I disagree.
It doesn't match a sample, but a sample is not a spec.
If you can describe what rule I've violated, that rule could become a
part of the spec.
(Think of that implementation as a stage in step-wise specification
refinement.)
Thanks
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
