clear model, clear sailing

[bowerbird]

michele said:
>   you're certainly allowed to start a discussion

i can try.

but when nobody responds, it's a failed effort.

which is exactly why i said i am not permitted...


>   After years of thinking about it,
>   I don't think this is actually possible.

then you didn't understand the point i was making
by the phrasing i chose when i posed the question.

flexibility is _orthogonal_ to inconsistencies.

and, when you do a careful job of sorting them out,
you realize that gruber is talking about flexibility,
while the critics are focused on the inconsistencies,
which means that they are talking past each other.

you could remove all the inconsistencies -- all! --
without having to sacrifice any room for flexibility.

then you are just left with the issue of ambiguities.
and you sort those by thinking them through clearly,
until you recognize where the decision-points exist,
and that is where the issues of flexibility come in.
general answers don't exist here, but specific ones
will present themselves fairly rapidly upon analysis.


>   A lot of people want to have a Markdown parser
>   in their own programming language, tailored to
>   their own needs, and they really often want to
>   be able to extend it to cover their own use case.

once you've specified the model clearly enough, you can
write pseudo-code that administers it, so you _should_
be able to code it in almost any programming language.

indeed, that is _exactly_ the test that you should have:
if you can't code the model, the model isn't good enough.
further, if you can't port the code to another language,
and another, and another after that, your model is bad.

and, because it seems that i need to remind you again,
i've written my own form of light-markup, so i _know_
with a great deal of certainty, that what i'm saying is so.

i have a model.  i have clear rules.  i have working code.
i have ported that working code to a variety of languages.


>   Because of differences between the tools available
>   in each language and programming environments,

nope.  sorry.  all you need are _string-arrays_and_loops_
-- anything more than that means that your model is bad --
and any decent programming language is capable of those.


>   different implementations use
>   different regular expression engines

if you're using regular expressions, you're doing it wrong.
(precisely because you can't count on them to be specific.)


>   or formal grammars, or they all the parsing logic in code.

you're making things more difficult than they need to be.
which is part of the problem, and why you have difficulty.


>   This variety of tools
>   make the tradeoffs different
>   for every implementers.

part of what i've said above should have led you to see that
you shouldn't _need_ lots of "implementers".  a good model
quickly leads to the pseudo-code ported to many languages.


>   Often, something that's easy to implement one way
>   with a set of tool will be hard to implement similarly
>   with another set of tool, and vice versa.

you're making it more hard than it needs to be.

one model, one pseudo-code, one code-base ported widely.

will each language's version be as efficient/graceful/fast
as it could be?  of course not.  but it won't matter, since
it _gains_ so much by being easily paralleled to the others.
(and all of them will be sufficiently efficient/graceful/fast.)


>   Getting all the edge cases to parse the same way

"edge cases" mean that your model isn't specific enough.


>   Getting all the edge cases to parse the same way
>   across dissimilar implementations is a noble goal

you assume "edge cases" and "dissimilar implementations",
which is why you think it is hard.  that's why you're wrong.


>   it has to be weighted with other goals
>   such as having good parsing performance,

i've never had slow performance.  even with big files.
or slow machines.  even big files on slow machines.


>   it has to be weighted with other goals
>   such as having good parsing performance,
>   ease of maintainability, and ease of
>   adding extra features tailored to some specific needs.

maintainability and customization are where i _shine._


>   A parser that sacrifice those three last things
>   to conform to some standard will only fill the niche of
>   those seeking everything to be parsed the same everywhere.

i don't "sacrifice" a thing.  and where it counts, i'm better.


>   From an implementer point of view,
>   unless a detailed standard is written
>   as a description of what your own parser does,
>   you'll have to spend a lot of time
>   tweaking things to match that standard.

again, letting each implementer decide their own parsing
is a recipe for inconsistencies which should be _avoided._

there is one model, which is developed as a dance between
developing specification and running code, and _that's_that._
once your model is done, so is your spec and pseudo-code.

you think this is hard because you are doing it wrong.

once you do it correctly, you'll see that it's very easy.

by the way, there is the silly idea running around that
there's some conflict between users and implementers.
this, too, is one terrible misconception.  once you have
a clear model, it's clear for users _and_ implementers.


>   if you want one or another Markdown flavor
>   to become the standard, you need to find a way
>   for its implementation to be included everywhere.

i couldn't care less about any markdown flavors.

i believe in light-markup.

and after being the best-friend to light-markup for a while,
in recent years markdown has turned into its worst enemy,
due to a downright refusal to recognize and correct flaws...


>   But with all the diverse language ecosystem we have,
>   and with the varied needs of different communities
>   using Markdown, that seems quite difficult to achieve.

it will be quite difficult for markdown to achieve that, yes.


>   I'd call that impossible.

maybe even "impossible".

but it's within reach for light-markup with a clear model.

-bowerbird