Re: Second expression in sequence confusion FreeLink <- "[[" .{&[>\]]} "]]"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
tty
Reply | Threaded
Open this post in threaded view
|

Re: Second expression in sequence confusion FreeLink <- "[[" .{&[>\]]} "]]"

tty
He Levente.

Thank you very much. This is a huge time saver.

I was literally reading the wrong documentation.

whew!

Where is this documented? I do not see it on the wiki link you sent me. 
Is it infferable from a class in the XTreams packages?

I looked over the XTreams tests classes yesterday and did not see any clues.
Do the test cases need improving? (I can contribute by doing the grunt work under supervision)

Also, what does "don't yield them" mean?

Does it mean the parser stays in its present spot?

thank you again.

t.

p.s. I have cc'ed squeak-beginners list on this message.




---- On Tue, 10 Sep 2019 20:30:07 -0400 Levente Uzonyi <[hidden email]> wrote ----

Hi Tim,

On Tue, 10 Sep 2019, gettimothy wrote:

> Hi Levente.
>
> If you don't have time for this, "No" is  a good answer.
>
> I have the WikiMedia freelinks working. https://en.wikipedia.org/wiki/Help:Wikitext#Free_links
>
> [[This Is A Link]] generates 
>
> <a href="https://en.wikipedia.org/wiki/This_is_a_link">This is a link</a>
>
> I would like to translate the FreeLink <- "[[" .{&[>\]]} "]]" sequence into something like
>
> FreeLink <- LinkOpen  .{&[>\]]}  LinkClose
> LinkOpen   <- BracketOpen BracketOpen
> LinkClose   <- BracketClose BracketClose
> BracketOpen <- "["
> BracketClose <- "]"
>
> so that I can iteratively build up to more complicated link styles.
>
> That Capture in the middle of the sequence is giving me fits.
> Something as simple as:
>
> FreeLink <- LinkOpen  .{&[>\]]}  LinkClose
>
> does not parse as neither LinkOpen nor LinkClose are consumed.
>
> My interpretation of that middle sequence term is:
> "." get the next character and consume it.
> {&[>\]]} apply expression &[>\]] and capture the string that matched it for later use.

In Xtreams-Parsing, braces don't mean capture. They mean cardinality. It
comes from common regular expression syntax.
The regular expression x{1,3} means x 1 to 3 times, so it accepts x,
xx, and xxx.
You can also pass a single number x{3}, which is a shorthand for xxx.
You can also omit the second argument like in x{3,}, which means x 3 or
more times.
This construct is extended in Xtreams-Parsing with a stop expression.
"x"{"y"} means, accept any number of x up until y comes. Consume y too,
but don't yield it. So, such expression accepts: xy, xxy, xxxy, xxxxy,
etc, and yields x, xx, xxx, xxxx, etc.

I suspect having & inside {} probably causes problems, because {} tries to
consume what it parses, but & tells the parser not to consume what comes
after it.

If I were to write the FreeLink rule, it would be something like:

FreeLink <- "[[" .{"]]"}

It means: take two opening braces, accept and yield everything up to two
closing braces, then consume those too, but don't yield them.


Levente

> &[>\]] AND predicate : indicate success if expression [>\]] matches text ahead; otherwise indicate failure. do not consume text.
> [>\]]  character range between ">" and "]"
>
>
> Thanks for your time.
>
> cordially,
>
> t
>
>
>
>
>
>
>


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners