doesn't that make you wonder?

[Tao Klerks]

OK, I interpret this (besides the quite-reasonable "why should I care?"
vibe), combined with previous references to the PEG grammar(s) implicit in
MultiMarkdown and peg-markdown's implementations, as "a formal specification
already exists".

 

That sounds fine - I'd love to use peg-(multi)markdown in my programs, but I
see two practical problems for that right now:

.         A C library, while portable to any processor architecture, if not
portable to any development environment, and certainly not future-proof. I,
personally, would like to be able to rely on the exact same syntax not only
across the OSs that Fletcher mentions, but also in C# code (that can be
sandboxed safely - no P/Invoke calls to unsafe code) and also in browsers.
There are numerous other environments (Java, etc) where a similar "safe
code" requirement precludes the use of a C library (at least in browser and
other high-sandboxing environments).

.         The PEG grammars(s) may be formal reproducible reusable
specifications, but my understanding is that they are not so meaningful
without a definition of what they map to. If my brief reading on this is
correct, a PEG grammar allows you to define behaviours to be executed upon
encountering certain source structures; those behaviours implement a
conversion to HTML, or latex, or whatever, but are implicit in the Program,
not the Specification/Grammar

 

So if we take the current PEG-based implementations as a starting point,
what would it take to produce a specification that formally establishes not
only the source structures to be matched, but also the behaviour/conversions
to be implemented against them? Is this just a question of detailed
documentation and an open test-suite?

 

Another applicable question is: are PEG grammars easily usable in other
environments? A brief search suggests so (js:
http://stackoverflow.com/questions/79584/are-there-any-parsing-expression-gr
ammar-peg-libraries-for-javascript-or-php, C#:
http://www.codeproject.com/KB/recipes/grammar_support_1.aspx not
GPL-compatible, sadly.); does anyone know how fesible it is to take the
existing PEG grammar(s) and reuse them in other languages?

 

Thanks,

Tao

 

 

From: markdown-discuss-bounces at six.pairlist.net
[mailto:markdown-discuss-bounces at six.pairlist.net] On Behalf Of Fletcher T.
Penney
Sent: Thursday, October 20, 2011 12:28 PM
To: Discussion related to Markdown.
Subject: Re: doesn't that make you wonder?

 

My "official" stance is:

 

1) I think consolidation is a good idea

 

2) consolidation is going to take time and effort

 

3) those of us who have written our own variants are probably happy with how
they work (or else we would have changed them already)

 

4) These developers, as individuals, might not actually see much benefit
from the time and effort it takes to standardize on something that, almost
by definition, will be less close to our own "ideal" markup than what we've
already written

 

5) Therefore, I think it's going to take some other purpose/benefit/reward
to help motivate the group to work on this.

 

 

That doesn't mean it's not a worthy goal --- just that it's going to take
some dedication.  And as I've stated here before, it's going to take a
clear, well-defined "mission statement" to help guide the effort.
Inevitably, some people will fall into the "kitchen sink" camp and will want
every conceivable feature.  Others, like myself, will prefer the smallest
number of features necessary to accomplish the needs of most (but not all)
users.  Without a clear mission statement, resolving these sorts of disputes
will be impossible.

 

 

Personally, I found John MacFarlane's peg-markdown to be a very compelling
program conceptually, and in its implementation.  The idea of a parsing
expression grammar (PEG) that could be reused for other purposes was
intriguing (though I had no idea what it was when I read about it...)

 

Moving MMD from perl to the PEG/C combo took several months of effort, and
required some changes to the MMD syntax.  But I feel like in the end I was
left with a program that was faster, more accurate, more useful, and more
compatible.  Additionally, I was able to take that PEG and with minimal
modifications use it as the basis for the highlighter in MMD Composer.  I
could never have done that with the perl script.  And with the PEG, I know
that both apps will interpret the source in the same manner (aside from any
bugs I may have introduced in the migration).  And any other developer that
wants to implement MMD in another language/environment/OS/whatever, can use
that PEG to ensure that their version of the MMD syntax matches mine.

 

 

I didn't always agree with every decision John made in defining the PEG for
peg-markdown (which forms the basis for peg-multimarkdown/MMD 3.0).  But he
always had well thought out, well articulated, reasons for his approach.  He
was very accommodating when I proposed changes, and was quick to fix bugs.
Agreeing to go with his interpretation was rarely a huge sacrifice, and the
benefits far outweighed any downside for me.

 

 

 

As a thought experiment, consider this perspective (some of which may be
true, some of it isn't true):

 

* MultiMarkdown suits my purposes quite well - I can create presentations
for lectures, formal letters on custom letterhead, I run several web sites
with it...  There's very little in the sphere of writing that it can't do
for me.

 

* I now have a GUI editor that "understands" MMD natively.

 

* There's not a popular text editing tool/app that I'm aware of (for the Mac
at least) that does not have requests out there asking for them to support
MMD.  That doesn't mean anyone will do anything about it, but the requests
are out there.

 

* Other developers are asking me about how to incorporate MMD (and some,
like Daniel Jalkut, have actively contributed to making that possible!)

 

* More and more apps *are* supporting MMD natively, in some fashion or
another

 

* I expect those numbers to grow now that MMD is a C program/library, and
when I clean it up enough to be easier for developers to use, I suspect it
will grow even faster

 

* I can change MMD any time I get a new itch that it doesn't already scratch
--- I don't have to wait on anyone, or worse, a committee of anyones

 

* I'm already busy maintaining MMD, responding to questions/support issues,
and now about to start selling a commercial app built around MMD ---  the
last thing I need is to give myself more work that might not show me much
benefit

 

* So, in my world, MMD is the #1, #2, and #3 variant.  (Not to say that is
true for anyone else, just for me)

 

 

So given these statements (again, some I agree with, some not, but I could
see other hypothetical developers in this situation citing them) ---
convince me that an effort to "standardize" would be worth my time and
effort?  What benefit am I going to see that justifies several more months
(years?) redoing my work?

 

 

 

 

Another part of this thread mentioned that perhaps there was a sweet spot
between Markdown and reStructuredText that was ripe for development. That
may be true, and if anyone pursues it, I wish them all the best.  But for
me, and I suspect others, I don't *want* something much more formal or
complicated than MD/MMD.  That's why I like MD.

 

What I *do* want is a more standardized approach to interpreting the
Markdown syntax.  My guess is that most users don't care which
interpretation of lists and indenting we use.  Or whether <strong>
supersedes <em> or vice-versa.  I think they just want it to work the same
way all the time, regardless of which program/application/platform they are
using.

 

 

 


>From that perspective, I'm fine with agreeing that the PEG from peg-markdown

becomes the canon for the core Markdown syntax in whatever new language we
create (subject to a round of debate/discussion on some of the edge cases).
Then, if there can be agreement on a mission statement for additional
features, the PEG can be extended to add other "second-tier" features (e.g.
tables, footnotes, metadata, etc.).  I believe that this second part is
going to be the more difficult and time consuming part, so why waste time on
the first part when it could be relatively easy.

 

 

 


:)


 

 

 

F-

 

 

PS>  Just to stir the pot a bit...  ;)  Since it seems clear that John
Gruber is no longer developing his own version of Markdown, it would be nice
if he would review whatever standard arises for the core feature set (not
any new features, just the original set - except footnotes - for goodness
sakes he all but wrote the footnote syntax himself and even used it on his
own site.  Just never implemented in Perl....  Please include footnotes...)

 

And then, if he agreed with it, John could sign off on calling it "Markdown
2.0" or whatever.  He (or someone else) could then update the perl script to
be compliant, if desired.  But at least there could be a well-defined
Markdown syntax that everyone could refer to as canon. It could form the
basis for a test suite that other others could use to claim their software
was "Markdown compliant."  It would then be up to various developers to
agree on a canon for alternate features (tables, metadata, etc) and this
would still need a different name.  But agreement on the core set would be a
huge start.

 

 

 

On Oct 20, 2011, at 9:20 AM, Sherwood Botsford wrote:





E.g.  Suppose that Fletcher is open minded, and eager for consolidation.
Further suppose that MMD is the #4 variant.  He contacts #1,2,3, and 5, and
asks if as a group they can agree on a spec.  #2 says, stuffit, but 1,3 and
5 agree.  They get together, and modify the code.  Each introduces a flag,
"-new" to the command line (or preferences for apps) to support the new
syntax during the transition period.  Later on -new will be the default
behaviour, and -traditional is used for the current behaviour.

If agreement is reached, then the group looks at variants 6,7,8,9 and
inquires if they would like to join in this effort.



 

--  

Fletcher T. Penney

fletcher at fletcherpenney.net

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20111020/aa974935/attachment-0001.htm>