From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bengt Richter Subject: Re: On DSLs Date: Tue, 3 Dec 2019 22:33:07 -0800 Message-ID: <20191204063307.GA1138@PhantoNv4ArchGx.localdomain> References: <87d0drscng.fsf@gnu.org> <87mucm4iyp.fsf@gnu.org> <877e3narto.fsf_-_@gnu.org> <11023A81-0C23-48F0-83E9-082D39343FAB@lepiller.eu> <87zhg98son.fsf@elephly.net> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:41123) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icOEB-0007ad-6U for guix-devel@gnu.org; Wed, 04 Dec 2019 01:33:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1icOE4-0001Cx-2t for guix-devel@gnu.org; Wed, 04 Dec 2019 01:33:30 -0500 Received: from imta-37.everyone.net ([216.200.145.37]:56944 helo=imta-38.everyone.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1icOE3-0000uV-NR for guix-devel@gnu.org; Wed, 04 Dec 2019 01:33:27 -0500 Content-Disposition: inline In-Reply-To: <87zhg98son.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org On +2019-12-03 15:12:32 +0100, Ricardo Wurmus wrote: >=20 > Konrad Hinsen writes: >=20 > >> Could this discussion be saved in the cookbook for instance? I'd lik= e > >> to have this kind of discussion on the approach of guix and ideas > >> behind it somewhere more accessible than the ML archive. Does it mak= e > >> 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 ;-) >=20 I would like to see useful info and tested guix (and related) usage examp= les 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 per= sonal 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 proposi= ng ... (well, sketching out half-baked proposal ideas :) ... that some sort of delimiting syntax be defined to make automated extracti= on 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-inspir= ed extension of the established: "--8<---------------cut here---------------start-----= -------->8---" delimiter. When a thread comes to an agreed conclusion, it should not be hard to wra= p a few paragraphs in appropriate delimiters. Maybe use rc-n versioning in leadup= ? I would suggest making delimited text unique too, by leveraging some pref= ix 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 lo= ts of existing parsing tools). But guix-specifically, for guile processing of text with mime-delimited s= ections, 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 s= yntax from other languages and of course unbalanced quoting and bracketing from lispy lang= uages. 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 e= mails and media already rendered as text (though of course lots can be done wit= h 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 w= hatever. I am working on something that incorporates very similar functionality, b= ut 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 constit= ute 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 l= inear 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 he= aders designed to make extraction of cookbook (knowledge-base?) materials from posts and= archives automatable, generating nice snippets with footnoted urls and attribution= s etc from email headers. --8<----(proposal)-----------cut here---------------end--------------->8-= -- --8<----(code contribution: untested)-----------cut here---------------st= art------------->8--- Comment: bash invocation of guile. guile -c $'(display "I am a code snippet")(newline)' --8<----(code contribution: untested)-----------cut here---------------en= d--------------->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 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 not sure boxes are a good idea =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=A4 =E2=94=82 > We can rename the cookbook to make it fit ;) =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 >=20 +------------------------------------------------------------------------= -+ | not sure boxes are a good idea -- ascii safer? = | +------------------------------------------------------------------------= -+ | > It was a placeholder name, because we all agreed for some time that a= | | > =E2=80=9Cdocument=E2=80=9D like that would be useful and that it shou= ldn=E2=80=99t be a wiki. | | > Beyond that we really didn=E2=80=99t have any plans. I went ahead an= d | | > started it to enable collaboration on this resource =E2=80=94 whateve= r 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 w= ell as plain. --8<---------------cut here---------------end--------------->8--- --=20 Regards, Bengt Richter