Re: [fyi] extensible syntax, syntax features, parsing risk

[John Kitchin <jkitchin@andrew.cmu.edu>]

[-- Attachment #1: Type: text/plain, Size: 5384 bytes --]

Is it related to
https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00404.html

I implemented that idea for fun once:
https://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/

John

-----------------------------------
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Sat, Dec 4, 2021 at 5:10 PM Samuel Wales <samologist@gmail.com> wrote:

> the quoted post below, which had message id
> 20524da70901041233g105f372fv175a47dc9884fa43@mail.gmail.com , starts a
> thread relevant to the current discussion of syntax, at least
> historically, maybe practically.  could not find it online.
>
> there were succeeding threads with examples and other stuff for id
> markers and graph-theoretic things and other examples, where you as
> user could always use a cl-like syntax [i.e. something like
> "$[functionality-name arg :keyword arg]"].  my main concern was the
> proliferation of syntax, and the risks of that [e.g. parsing] and
> wanting the ability of factoring of syntax features.
>
> display, parsing and so on would be shared [factored] among all the
> different such features; org would always handle that the same.  thus
> as a user even, you could add some new feature in lisp, and write it
> in org using this syntax.  it would already work.
>
> i have more in notes.  idk if it is still relevant, but i have
> included the thread starter for the earliest thread [carsten/myself].
>
> On 1/4/09, Samuel Wales <samologist@gmail.com> wrote:
> > A general idea, which might or might not be useful.
> >
> > There are occasionally questions about syntax, like this:
> >
> >   Also, I'm afraid definition matching regexp won't play
> >   nicely with text indentation, ... -- Paul
> >
> > Or this:
> >
> >   What would be safer?  -- Carsten
> >
> > I like the footnote implementation, so this is for future
> > features, not necessarily footnotes.
> >
> > One issue when implementing new syntax (or changing existing
> > syntax or cleaning up code) is parsing risk, which I will
> > define as the risk that the syntax and the regexp or
> > matching code:
> >
> >   1) conflicts with user text
> >   2) conflicts with existing features
> >   3) will be hard to maintain
> >   4) constrains future features by making them conflict
> >      syntactically
> >   5) makes you run out of syntax to use in the future
> >   6) will require complicated regexps
> >   7) doesn't readily handle stuff you might want in the
> >      future, like being combined with another feature
> >   8) will be hard to quote, escape, comment, *boldify*, etc.
> >   9) doesn't handle nestability, print-readability,
> >      pretty-printability, syntax coloring, etc.
> >   10) will be inefficient when called in a loop
> >   11) isn't factored out
> >   12) etc.
> >
> > For example, one of the many reasons for using org-IDs (:))
> > in the conversation manager (as proposed) is that there are
> > already functions to parse org-IDs, so a new syntax is not
> > necessary and therefore parsing risk is minimized.
> >
> > In case parsing risk is a concern when adding a new feature
> > to org, here is one idea: have a generic syntax that is
> > extensible with keywords.
> >
> > The idea is to have a bracketing syntax with a reserved
> > keyword as the first element that says what you are doing.
> >
> > To use footnotes as an example (this is not a suggestion to
> > change footnote syntax, just an example that can be used for
> > future syntax):
> >
> > You might use something like "here is some text to be
> > footnoted $[fn apple]" to specify the footnote link, and
> > "$[fn-target apples are delicious]" to specify the target.
> >
> > The general point I want to make is that once such a syntax
> > is decided on, many future features are possible without
> > introducing parsing risk.
> >
> > For example, you can implement a new feature as
> > "$[my-new-feature ...]".  Then there is no parsing risk,
> > even though you have just added a new feature.
> >
> > For modifications of features, you can use keywords:
> > "$[my-new-feature ... :myparameter ...]".  These are easily
> > parsed by standard functions for parsing lists.
> >
> > You can develop ways to boldify, quote, nest, prettily
> > print, etc. this syntax, and those ways will work well with
> > all future features that use it.
> >
> > Of course, the dollar sign and brackets are not the only
> > possibility; it could be percent sign and parentheses, for
> > example.
> >
> > You will not be starting from scratch.  Lisp has already
> > worked out many of these issues.
> >
> > I will leave it to those who write massive amounts of org
> > code to decide whether an extensible syntax might be useful
> > to reduce parsing risk for future features.
> >
> > But I thought that I would propose the idea in case it is of
> > interest.
> >
> > --
> > For personal gain, myalgic encephalomyelitis denialists are knowingly
> > causing further suffering and death by grossly corrupting science.  Do
> > you care about the world?
> > http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm
> >
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>
>

[-- Attachment #2: Type: text/html, Size: 7287 bytes --]