Sv: Sv: Sv: Christmas wish: Literate Elisp

[arthur miller <arthur.miller@live.com>]

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

Hello, sorry for a bit late answer, but I was very busy Monday/Tuesday.

To make this more readable I will try to summerize here as one-piece text
for easier reading.

As you mention yourself from,Wikipedia, literate programming is about moving
away from programming for computers to programming for humans. Using comments
to comment-away text ment for humans or to mark lines between comments and
code is indeed writing for the computer, not the human. Humans tend to be
distracted by unnecessary clutter, and managing stuff just for the sake of
machine does take a little more effort then not doing it.

Being programming-language agnostic though is probably not possible
without having some kind of special tool, or special syntax due to some
languages being probably very hard to distinguish from ordinary text. For
example I believe that C/C++ or even Bash or Makefiles are very hard if
not impossible to process that way without some very complicated parser. I
can also imagine case where Elisp is impossible to distinguish from text,
(for example this line is valid text but would fail in parser), or whatever
we would put into a parenthesis on a separate line that does not belong to code.

Anyway, due to elisp looks, we have those "natural markers", ( and ) which
we can use as delimiters between code and text.

For the question of being concerned about omitting ';' to change the parser.
Well yes :-). Small syntactic sugar change but it reduces that visual clutter.
It is one step in that direction of writing code for humans and not for the
computer. See it as experiment. I thought it would be a cool thing to have. It
is just an idea. The change is not in an intrusive way. All your elisp is
still very same. It just adds an extra feature pretty much for free. If it would
be an intrusive change that requires your old elisp to change, than I wouldn't
suggest it. By the way, one could also add a variable to turn off that feature.

As for the tools, since old elisp code does not change, all your tools would
still continue to work on all your ordinary elisp, and you could still use ';'
just as you do now. What would change is that you would be able to write some
elisp as you can't now, and only on that code the tools would probably get
confused. I have no idea how hard would it be to change font-locking and
indentation checkers, maybe hard, maybe not at all. I can't answer that since I
am not acquianted with how those tools are implemented (lots of regex as I have
heard). But in worst case, you can always fall back on writing ordinary elisp.

As a note, one will still have to use ';' in directives, like ;;;###autoload
or ;;; -*- lexical-binding: t; -*- . Otherwise it would need lots more work
to get it to work, which I am not sure is worth.

Från: Adam Porter<mailto:adam@alphapapa.net>
Skickat: den 17 december 2019 12:07
Till: emacs-devel@gnu.org<mailto:emacs-devel@gnu.org>
Ämne: Re: Sv: Sv: Christmas wish: Literate Elisp

arthur miller <arthur.miller@live.com> writes:

> It is true, that keeping directives in comments does not break the
> existing parser, but then it is not so much of literate programming,
> is it?

Literate programming is not a matter of syntax.  For example, this
summary in the Wikipedia article seems to describe it well:

  Literate programming is a programming paradigm introduced by Donald
  Knuth in which a computer program is given an explanation of its logic
  in a natural language, such as English, interspersed with snippets of
  macros and traditional source code, from which compilable source code
  can be generated.

  The literate programming paradigm, as conceived by Knuth, represents a
  move away from writing computer programs in the manner and order
  imposed by the computer, and instead enables programmers to develop
  programs in the order demanded by the logic and flow of their
  thoughts. Literate programs are written as an uninterrupted exposition
  of logic in an ordinary human language, much like the text of an
  essay, in which macros are included to hide abstractions and
  traditional source code.

  Literate programming (LP) tools are used to obtain two representations
  from a literate source file: one suitable for further compilation or
  execution by a computer, the "tangled" code, and another for viewing
  as formatted documentation, which is said to be "woven" from the
  literate source. While the first generation of literate programming
  tools were computer language-specific, the later ones are
  language-agnostic and exist above the programming languages.

None of that requires un-prefixed comment syntax.  Consider examples of
actual, full-scale literate programming projects, which are written in a
variety of languages and source code formats.

> If we would just use directives in comments then we already have org +
> babel. But I think 4 extra lines of C code to enable this feature in
> eval-loop was a trivial price to pay :-).

Changing the canonical parser of a widely used language would have
effects reaching far beyond the parser's native software.  Consider all
other software which parses Elisp, e.g. syntax highlighting tools
outside of Emacs, which would not correctly highlight these un-prefixed
comments you propose.  As well, consider other implementations, like
Guile's, which would also have to be adjusted.  Then consider all the
code linting tools which would likely need fixing.  It's not merely a
matter of 4 lines of code in an Emacs source file.

As has been mentioned, benefits such as outlining are easily achieved
with existing tools, some of which are even built-in to Emacs
(e.g. outline-minor-mode for simple outlining in Elisp files, and
org-mode for prose-first, noweb-style source files).

Are you really so concerned about omitting a semicolon at the beginning
of top-level comment lines that you want to change the Elisp parser?



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