
Major mode for editing SEML (S-Expression Markup Language) files - somezero
https://github.com/conao3/seml-mode.el
======
tgbugs
I've been using SXML [0] for all my sgml needs in Racket and the quality of
life improvement from having a sane and regular syntax for everything is hard
to overstate. seml looks like it might have the same kind of quality of life
improvements for some of my elisp-only code. I'm not sold on the way that
missing attributes are handled using nil, that seems like a design decision
that was made to simplify parsing at the expense of making the representation
more cluttered.

[https://docs.racket-lang.org/sxml/](https://docs.racket-lang.org/sxml/)

~~~
agumonkey
It's funny how the lisp/fp often remove irregularity, at the cost of
abstraction [0], which makes people pulling their hair off to the point of
going back to simpler but irregular separate logical tools. Even if they
complain about it very .. regularly.

[0] some people can't bear lisp uniformity for instance.

~~~
chriswarbo
Keep in mind that Lisp (including SXML) can be written in many ways
(parenthesised, indentation based, braces, infixed, prefixed, etc.), which can
be mixed and matched within the same expression, and can be trivially
converted between automatically.

I bring this up so often that I have a go-to blog post for it:
[http://chriswarbo.net/blog/2017-08-29-s_expressions.html](http://chriswarbo.net/blog/2017-08-29-s_expressions.html)

------
zeveb
I used to spend a lot of time manually typing up examples of why S-expressions
are cleaner and more readable than XML, HTML, JSON, YAML &c. They are, they
really are. And yet for some reason there's a population of people who prefer:

    
    
        <!DOCTYPE html>
        <html lang="en">
            <head>
                <meta charset="utf-8"/>
                <title>sample page</title>
                <link rel="stylesheet" href="sample1.css"/>
            </head>
            <body>
                <h1>sample</h1>
                <p>
                    text sample
                </p>
            </body>
        </html>
    

to:

    
    
        (html ((lang . "en"))
              (head nil
                    (meta ((charset . "utf-8")))
                    (title nil "sample page")
                    (link ((rel . "stylesheet") (href . "sample1.css"))))
              (body nil
                    (h1 nil "sample")
                    (p nil "text sample")))
    

I don't understand it, but it seems to be true. The egotistical part of me
feels that they just haven't experience the enlightenment of understanding the
benefits of have all data & code be manipulable, structured data rather than
dead text which must be painstakingly parsed, combined with the benefits of a
_single_ , general, universal, cheaply-parseable representation.

But the professional, open-minded part of me wonders if maybe _I_ am missing
the point. Maybe all that painful-to-parse, irregular syntax is buying
something. Maybe there's a reason every generation for the last 50 years has
been approximating some but not all of the features of Lisp. Maybe those other
languages and formats have worthwhile benefits. Maybe they're even superior.

Or maybe most folks really are stuck in a local maximum, like kids who like
being read to and don't see the advantage of learning to read. I honestly
don't know.

Regardless, SEML looks great.

~~~
nfoz
Your example (and all the SEML documentation it seems) is missing marked-up
text. For example, how would you represent:

    
    
        <p>This is a <b>really cool</b> sentence.</p>
    

Your solution will probably have to splice the text segments around the
embedded markup, something like:

    
    
        (p nil (text "This is a " (b nil "really cool") " sentence."))
    

In particular, notice the careful whitespace at the edges of the strings.

IMO this Sexpr is now more obtuse than the XML, and the more markup you have
within text-spans (e.g. nested markup), the worse it gets. This is also a
major difference between XML (markup language) vs JSON (data-structure
notation).

Maybe you don't need the (text ...) thing, but either way you're changing the
grammar. How do SEML and SXML handle this?

~~~
undersuit
The issue is the spaces, so let's get rid of them!

    
    
        (p nil (text (string-join '("This" "is "a" '(b nil "really") '(b nil "cool") "sentence.") " ")))
    

No more wondering if the space between 'really' and 'cool' should be bold and
no need to have awkward preceding and trailing padding.

------
tlavoie
Makes me think of Edi Weitz's CL-WHO, which works very nicely if creating web
pages from Common Lisp. [https://edicl.github.io/cl-
who/](https://edicl.github.io/cl-who/)

------
notduncansmith
This reminds me very much of Hiccup[1]. Both nested s-expressions and HTML
describe trees.

[1]
[https://github.com/weavejester/hiccup](https://github.com/weavejester/hiccup)

~~~
StreamBright
I really like Hiccup, it is my favorite part of the Clojure web kit.

------
Lowkeyloki
This is interesting. It reminds me of the API behind JSX. But I'm not sure
what problem this is seeking to solve exactly. Is it showing that HTML and
s-expressions are technically interchangeable?

~~~
txru
If you have time, this[0] is the canonical article usually shared around this
concept. The thrust of it is that yes, XML (or x-expressions) and
s-expressions are very similar, and that s-expressions are a less verbose and
simpler way to represent data.

[0]
[https://www.defmacro.org/ramblings/lisp.html](https://www.defmacro.org/ramblings/lisp.html)

~~~
jakear
Skimmed the article, left me a bit confused. Am I missing something big, or is
this not particularly novel? The similarities between a-expressions and XML
seem fairly obvious to me.

~~~
txru
Well, it is and isn't novel. S-expressions have been around since McCarthy,
XML since the mid-90's. The point of the article is that XML is a more verbose
re-interpretation of s-expressions-- it's hard to find things that XML brings
to the table that sexps don't have. What's more, inside editors, there are
really clever things that manipulate sexprs, move them around, redefine their
semantic meaning. XML usually doesn't work quite that way, not as a first
intent.

~~~
tannhaeuser
SGML has been around since the 1960s, and XML is specified as a proper subset
of it. SGML/XML isn't so much about (trivial) nesting than it is about content
models, eg. the language defined by a regular expression admitted/recognized
as the content of a particular element. Markup is also first and foremost a
plain text format, _optionally_ tagged by start-/end-element tags, unlike
sexprs which need quotes around individual spans of text. Try telling an
author to use verbose quoting (and escaping for quotes) for what makes the
majority of his text format, or try edititing a large text with verbose sexpr
yourself, and you'll see why nobody uses sexprs for semistructured text.

~~~
txru
I take your point, and I really don't want to be the spark of a syntactic
flamewar. I suspected I was missing something, and that the
$angle_bracketed_format was older, but I was searching the wrong things.

It seems to me, though, that escaping is just something that's going to be
tricky everywhere, and a decent first line solution, wherever you are, is to
have a really rare set of characters represent your begin/end string marks. In
Python, """text""", Postgres has $$text$$, non-ASCII characters in other
formats. XML and sexps are both susceptible to that issue-- both of their
escapes are, themselves, escapable. To either one, if you have a subregion
that's likely to be unintentionally escaped, then you create a boundary where
you either explicitly escape every one, or you refuse to acknowledge
previously accepted delimiters. As an example, lisps have (quote term) rather
than 'term when you're writing macros and concerned with macro-expansion.

To your regex point, there are lisps that definitely did awful deeds with
that, particularly emacs lisp, but the more recent ones have solutions just
like other modern programming languages and markups do.

To me the unending escape just kind of seems like a universal bug. While lisp
is just as susceptible, lisps have perfectly reasonable ways of treating these
problems-- separate, make distinct, and as last resort, escape.

