If this counter existed, it would need to be internal to ;:
Or, if the parsing algorithm were to be implemented in J, this part of
the algorithm might be expressed using +/\.
But there's a potential interaction between quote handling and comment
handling and dd brace handling and line end handlin
I don’t quite understand.
Do you mean instead of pushing to the stack,
you increment the counter,
and instead of popping from the stack,
you decrement the counter?
So the counter needs to be part of the respective
locale’s (namespace’s) name, right?
(stack based evaluation always reminds me of FOR
I am not sure what you mean here.
In the current 902 beta-k, I get an error and not a tokenization with
an unbalanced quote:
;:'asf''asdf'
|open quote
If you are talking about the {{ }} nesting -- the implementation
doesn't actually use the ;: monad for that. Instead, it uses a
technique where
I was going to look at this very state machine the other day. The original
machine has one property that I have found very useful.
It can handle unbalanced quotes on the code lines. Monadic pre 9.02 ;:
throws errors and does not return the tokenization.
The JOD system tokenizers J code in som
I thought that might be the case. I would rather add to (x ;: y), if
you know just what's needed.
Henry Rich
On 11/4/2020 12:01 PM, Raul Miller wrote:
After studying this: the rules you implemented for {{ and }} require
either an additional sequential machine operation (somewhat analogous
to
After studying this: the rules you implemented for {{ and }} require
either an additional sequential machine operation (somewhat analogous
to ev, but non-repeating), or post-processing the result (to break up
offending {{. and {{: sequences).
FYI,
--
Raul
On Wed, Nov 4, 2020 at 11:08 AM Henry R
To avoid breaking existing code that uses {{. .
Henry Rich
On 11/4/2020 11:07 AM, Raul Miller wrote:
Oh, yes.. hmm...
Looking at what I tested, I see that I messed up that test. (For some
reason, I just tested the ;: monad there.)
That said... remind me again why the {{ and }} rules do not fo
Oh, yes.. hmm...
Looking at what I tested, I see that I messed up that test. (For some
reason, I just tested the ;: monad there.)
That said... remind me again why the {{ and }} rules do not follow the
same pattern as any other tokenization when dealing with . and :
characters?
Thanks,
--
Raul
(0;sj;mj)&;: '{{.'
+---+
|{{.|
+---+
;: '{{.'
+-+--+
|{|{.|
+-+--+
(0;sj;mj)&;: 'NB. comment' , 10 48 10 { a.
+--+
|NB. comment 0 |
+--+
;: 'NB. comment' , 10 48 10 { a.
+---+-+-+-+
|NB. comment| |0| |
+---+-+-+-+
Henry Rich
On 11/4/2020 10:27
sorry, my fault
Am 04.11.20 um 16:34 schrieb Raul Miller:
> The 9 there is a label, not a count.
>
> Look at the other lines to see the pattern.
>
> For the new lines I added, I elected to just use the character itself
> as the label (but this would cause an alignment problem for the '
> charact
The 9 there is a label, not a count.
Look at the other lines to see the pattern.
For the new lines I added, I elected to just use the character itself
as the label (but this would cause an alignment problem for the '
character if I tried using this approach on that line).
Thanks,
--
Raul
On W
it’s 10 digits, not 9
Am 04.11.20 um 16:27 schrieb Raul Miller:
> This needs more extensive testing, but I believe that I have an
> updated mj and sj for
> https://www.jsoftware.com/help/dictionary/d332.htm which delivers the
> new behavior for the ;: monad with (0;sj;mj)&;:
>
> (beware email ind
This needs more extensive testing, but I believe that I have an
updated mj and sj for
https://www.jsoftware.com/help/dictionary/d332.htm which delivers the
new behavior for the ;: monad with (0;sj;mj)&;:
(beware email induced line wrap).
mj=: 256$0 NB. X other
mj=: 1 (9,a.i.'
13 matches
Mail list logo
