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
