Re: Tentative design of markdown parser

[Natasha Kerensikova <lithiumcat@gmail.com>]

Hello,

On 2011-05-28, Yannick Duchêne <yannick_duchene@yahoo.fr> wrote:
> Le Sat, 28 May 2011 15:22:17 +0200, Natasha Kerensikova  
><lithiumcat@gmail.com> a écrit:
>> type Element_Priority is delta 2.0**(-15) range 0.0 .. 1.0;
>>
>> type Span_Element is record
>>   Active_Char : Character;
>>   Priority : Element_Priority;
>>   Lexer : Lexer_Callback;
>>   Renderer : Renderer_Callback);
> I've the Rationals part which I may read later, and did not already  
> searched the web for what Markdown is, so I may missed some point.

I didn't consider deep understanding of Markdown as a prerequisite, but
it might be useful (and should be enough) to know that it's a markup of
raw text supposed to be as close as possible as e-mail conventions, like
using enclosing *stars* or _underscores_ as emphasis, lines starting
with '>' to denote blockquotes, etc.

> What is Element_Priority ? A kind of Order-of-precedence ?

I guess kind of order-of-precedence. More precisely, some Lexer_Callback
are less specific than others (and in the implementation of Markdown I
have in mind, there is even a catch-all lexer that produces tokens out
of anything that hasn't been recognized by something else), so I felt
the need of a way to order them from the most specific to the least
specific, and without any information about Lexer_Callback, it has to be
done manually.

> Span_Element is a structure, with no constructor ? What returns  
> instance(s) of Span_Element ?

Nothing. I thought of Span_Element as just a bunch of variables,
initialized by the client and provided (read-only) to the library
subprograms.

>> type Lexer_Callback is access procedure (
>>   Source : String;
>>   Position : in out Positive;
>>   Renderer: Render_Callback);
> Lexer_Callback get a parameter of type String, but nowhere I can see a  
> structure holding a type String. Seems the interface does not show all the  
> relations between all the stuffs.

What you're probably missing is the main subprogram of the library (I
only written types). I don't have a clear idea of what it would look
like, but probably something similar to

function Parse (
  Source : String;
  Parser_Description : Span_Element_List)
return String;

The data flow is the client filling the array of Span_Element, and
sending it along with the input text (as String) to the Parser function.

The parser function scans the Source, and that internal scan position is
what would become the Position parameter passed to Lexer_Callback.

Then the Lexer_Callback crafts a Token object, sent to the
Render_Callback, which produces a text output of some yet-undefined form
(maybe a String or something more complex and better suited). The text
output goes up the stack frames from Render_Callback to Lexer_Callback
to Parse where it's accumulated, and eventually the whole processed text
is returned (as String in the above declaration, but it might as well be
using a better suited text-holding type).

> Position is in/out, so something should hold at least a corresponding  
> element of the same type Positive, which would be mutable. I could not see  
> such a thing. Same as the above comment, I feel the interface does not  
> show some relations which are supposed to be “guessed”.

Indeed, I've never meant that type list to provide enough information.
The "guessed" part is supposed to come from the description of how it
works (which is immediately before the actual rationale).

> Sorry if my questions seems stupid, as I suppose everything looks very  
> clear in your own mind.

Not really stupid, you just used a part of my post that I didn't mean to
be standalone. I don't feel the design to be mature enough in my head to
actually write a specification file (I have a clear enough sketch in my
head, but I'm missing some Ada type details to reach that point, and I
was sort-of hoping to get help from the group in figuring out these
details). But when that's the case, that won't be a bunch of types like
my post, but a well-commented standalone Ada text.


Thanks for your comment,
Natasha