Re: On DSLs

[Bengt Richter]

On +2019-12-03 15:12:32 +0100, Ricardo Wurmus wrote:
> 
> Konrad Hinsen <address@hidden> writes:
> 
> >> Could this discussion be saved in the cookbook for instance? I'd like
> >> to have this kind of discussion on the approach of guix and ideas
> >> behind it somewhere more accessible than the ML archive. Does it make
> >> sense?
> >
> > I think it makes sense to archive summaries of such discussions. I am
> > less convinced that the cookbook is the right place, because design
> > principles are pretty much the opposite of what I'd expect in a
> > cookbook. But I don't see any better place and multiplying the parts of
> > the documentation isn't great either. So... I am undecided ;-)
> 

I would like to see useful info and tested guix (and related) usage examples
accumulate in a knowledge base for easy searching and extraction, however it's 
named.

I regularly snip out examples from developer postings as grist for my personal
how-to notes, but that doesn't help others, and no common resource grows.

I think as much as possible ought to be automated, therefore I am proposing
... (well, sketching out half-baked proposal ideas :) ...
that some sort of delimiting syntax be defined to make automated extraction
and re-presentation of search results easy and effective.

I think the mailing list archives could serve as a knowledgebase if
desirable posting content in our emails were delimited with a MIME-inspired 
extension
of the established: "--8<---------------cut 
here---------------start------------->8---"
delimiter.

When a thread comes to an agreed conclusion, it should not be hard to wrap a few
paragraphs in appropriate delimiters. Maybe use rc-n versioning in leadup?

I would suggest making delimited text unique too, by leveraging some prefix 
characters
of base32 of content, along with some identifying info. Side benefit: big search
engines will find them for you, wherever copies wind up.

In fact, if we adopted real MIME multipart delimiters with the final one ending 
with
"--" appended, it would open many possibilities (and probably tap into lots of 
existing parsing tools).

But guix-specifically, for guile processing of text with mime-delimited 
sections,
maybe someone --( I tried some time ago, but got no sa-tis-faction ;-/ )--
could make a guile module that could be imported to define a reader macro e.g.
like #--"boundary" which would chew through input and convert
it into a list of (header . content) pairs until the final "\n--boundary--" is 
encountered.
Think of it as a super-quote that can quote anything, even broken quote syntax 
from other
languages and of course unbalanced quoting and bracketing from lispy languages.
Hm. maybe a special #L language switch to do the parsing?

Anyway, both the header and the content of the macro output pair would be 
string,
since I am just sketching a way to quote and identify desirable text in emails
and media already rendered as text (though of course lots can be done with the 
raw email).

This would serve as a way to quote "foreign" language source for use
embedded in guile code. You could quote make files and bash scripts and 
whatever.
I am working on something that incorporates very similar functionality, but I 
offer
this misleading mish-mosh so you won't die holding your breath :)

--proposed sketch for mime reader macro
Comment: part 1: reader macro usage example

(define mime-stuff #--"ad lib"
  garbage up to first delimiter is first header like rfc0822
--ad lib
first header

first content after blank line
no newline
--ad lib

content with default header
content ends with newline

--ad lib--
;; reader macro exits, normal reader resumes
)

--proposed sketch for mime reader macro
Comment: part 2: net effect of reader macro
Comment: just out of my head, totally untested, just to get the idea out

;; so the above reader macro incantation becomes equivalent
;; in result as if this had been written instead
(define mime-stuff '(\
("  garbage up to first delimiter is first header like rfc0822" . "") \
("first header" . "first content after blank line\nno newline") \
("" . "content with default header\ncontent ends with newline\n" ))
)

--proposed sketch for mime reader macro--

see (proposal) below for another way of tagging snippets ;-)

--8<---------------cut here---------------start------------->8---
Comment: The immeadiatly above typical guix snippet delimiter
 might be a legal MIME delimiter, even though it's not paired with the
 identical line with "--" appended to form the ending delimiter.
Comment: per rfc0822 the first lines after the starting delimiter constitute
 a header, terminated by a blank line. Header lines may be folded
 by breaking linear whitespace to a new line starting with at least one linear
 white space char, like these two Comments: lines.

So this line is the first content line, following the blank line.

This is still content, including blank lines, up to the final delimiter.

--8<----(proposal)-----------cut here---------------start------------->8---

This is nested and tagged as "proposal"
I think using the existing guix delimiter style, we could add tags and headers 
designed
to make extraction of cookbook (knowledge-base?) materials from posts and 
archives
automatable, generating nice snippets with footnoted urls and attributions etc
from email headers.

--8<----(proposal)-----------cut here---------------end--------------->8---

--8<----(code contribution: untested)-----------cut 
here---------------start------------->8---
Comment: bash invocation of guile.

guile -c $'(display "I am a code snippet")(newline)'

--8<----(code contribution: untested)-----------cut 
here---------------end--------------->8---

--8<----(possible markup for extraction)-----------cut 
here---------------start------------->8---
Comment: would X-Content-Type: dangerous?;
 be bad here? Not sure of the rules. Email should just encapsulate what I 
write, so
 we should be able to process as we wish with custom tools, IWT

┌────────────────────────────────────────────────┐
│         not sure boxes are a good idea         │
├────────────────────────────────────────────────┤
│ > We can rename the cookbook to make it fit ;) │
└────────────────────────────────────────────────┘
> 
+-------------------------------------------------------------------------+
|             not sure boxes are a good idea -- ascii safer?              |
+-------------------------------------------------------------------------+
| > It was a placeholder name, because we all agreed for some time that a |
| > “document” like that would be useful and that it shouldn’t be a wiki. |
| > Beyond that we really didn’t have any plans.  I went ahead and        |
| > started it to enable collaboration on this resource — whatever it may |
| > become eventually.                                                    |
+-------------------------------------------------------------------------+

--8<----(possible markup for extraction)-----------cut 
here---------------end--------------->8---

HTH trigger some ideas :)
Here comes the final delimiter, guix style, not real mime terminal delim,
recognized by having skipped paired  "--8<----(something ..." delims as well as 
plain.
--8<---------------cut here---------------end--------------->8---

-- 
Regards,
Bengt Richter