From: Gene <gene.sullivan@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Define skeleton from alist?
Date: Thu, 14 Jul 2016 18:13:09 -0700 (PDT) [thread overview]
Message-ID: <c55a19ed-7d3b-4ac1-a331-38044179be8b@googlegroups.com> (raw)
In-Reply-To: <mailman.1366.1468458751.26859.help-gnu-emacs@gnu.org>
On Wednesday, July 13, 2016 at 9:12:33 PM UTC-4, Paul Rankin wrote:
> Gene on Wed, 13 Jul 2016 14:37 -0700:
> > At first blush it seems as you might have an impoverished mental model
>
> Okay.
>
> > Thus I present the following for your `eval'uation:
> >
> > (mapcar 'identity fountain-title-page-list)
> >
> > (mapcar (lambda (elt)(identity elt)) fountain-title-page-list)
> >
> > (mapcar (lambda (elt)(car elt)) fountain-title-page-list)
> >
> > (mapcar (lambda (elt)(cdr elt)) fountain-title-page-list)
> >
> > (mapcar (lambda (elt)(cons (car elt)(cdr elt))) fountain-title-page-list)
>
> None of this produces a skeleton. See (info "(autotype) Skeleton Language")
I'm not sure whether to respond with `Point taken' or `Really?'
If I were to acknowledge my failure to unequivocally reveal how `cons' can be used to CONStruct any/every list type -- alists and skeletons included -- then I'd have to concede my failure via `point taken'.
As the `cons' in the subexpression `(cons (car elt)(cdr elt))(cons (car elt)(cdr elt))' reveals how to CONStruct atomic elements into some of the components in both an alist and skeleton I might be tempted to chock this up to failure of imagination ... especially given that `car' and `cons' are inverses which allow analytical decomposition and synthetic composition, respectively.
The point of my one-liners was to reveal the low-level cons_cell-cum-list operators and how they can be used to both decompose and compose lists ... of which both alists and skeletons are -- arguably -- subspecies.
As strings are employed in Skeletons I'll provide the following inverses to reveal how to decompose then recompose a string encoding some of that info you suggested I read:
(let ; this be evaluated to generate a side-effect in the form of a demo
(
(string
"Skeletons are an shorthand extension to the Lisp language, where various atoms directly perform either actions on the current buffer or rudimentary flow control mechanisms.
Skeletons are interpreted by the function skeleton-insert.
A skeleton is a list starting with an interactor, which is usually a prompt-string, or nil when not needed, but can also be a Lisp expression for complex read functions or for returning some calculated value.
The rest of the list are any number of elements as described in the following table:"
);string
(sentence-end ". ")
(word-delimiter " ")
list-of-sentences
list-of-words-within-sentences
sentences-from-words
paragraph-from-sentences
)
(setq
list-of-sentences
(split-string ; the inverse of mapconcat
; 'identity ; FUNCTION ; this argument is needed by mapconcat, though not split-string
string ; STRING ... which corresponds with SEQUENCE after the string has been split to form a list useable by mapconcat
sentence-end ; SEPARATORS ... which corresponds with SEPERATOR -- singular -- when used by mapconcat
)
)
(setq
list-of-words-within-sentences
(mapcar
(lambda (sentence)
(split-string
sentence
word-delimiter
))
list-of-sentences
)
)
(setq
sentences-from-words
(mapcar
(lambda (list-of-words)
(mapconcat ; the inverse of split-string when both use mutually-compatible arguments
'identity ; FUNCTION used to concatenate substrings into larger, synthesized, composited strings
list-of-words ; SEQUENCE
word-delimiter ; SEPARATOR
))
list-of-words-within-sentences
)
)
(setq
paragraph-from-sentences
(list) ; to be replaced via (mapcar (lambda mapconcat)) FUNCTIONAL construct by those following the demo-cum-exercise
)
(list
(cons 'string string)
(cons 'sentence-end sentence-end)
(cons 'word-delimiter word-delimiter)
(cons 'list-of-sentences list-of-sentences)
(cons 'list-of-words-within-sentences list-of-words-within-sentences)
(cons 'sentences-from-words sentences-from-words)
(cons 'paragraph-from-sentences paragraph-from-sentences)
)
)
I agree that I didn't provide a complete set of dots to connect.
I hope you'll agree that I DID provide `cons' as a means of ultimately connecting an ordered set of metaphorical dots, as well as `car' as a means -- perhaps recursively as with mapcar -- to decompose/deconstruct both partially and completely composed lists ... be they `be' or SEEM either alists or skeletons.
Reminder from info: "A skeleton is a list starting with ..."
Thus a skeleton as A LIST can be CONStructed via functional paradigm as well as statically created via the declarative paradigm.
I have responded to your admission "My feeble non-functional attempt at the define-skeleton: " as if you might be interested in clues on how you might bridge the gap between your essentially `declarative' first attempt and whatever perhaps-hybrid implementation you end up with.
Admittedly, perhaps you want a quick and direct solution which doesn't entail squandering time or getting your hands dirty at a lower-than-necessary level of detail.
If so ... NEVERMIND!
As John Mastro seems to have addressed your problem at a/the level you desired I suppose we can consider this issue closed.
Hopefully some of the from-the-ground-upwards and take-it-appart-then-put-it-back-together-again programmers out there might get some use out of my examples involving analytic-synthetic inverses.
Cheers!
Gene
P.S. Although perhaps you personally have low to no interest in metaprogramming, I'll reveal that the use of the functional paradigm to CONStruct your otherwise static data structure put's one's mindset several steps closer to exploiting metaprogramming to CONStruct static-declarative -- TO THE REST OF THE WORLD -- `code'.
Any/every alist and skeleton can be disassembled into a recipe via `car' and its relatives in the `mapcar' family.
Then this recipe -- using `cons' to correspond with the `car' function used to disassemble either the alist or skeleton -- can be `eval'uated to produce the quasiStatic data structure originally implemented -- if not conceived -- via the declarative paradigm.
In a sentence, one can start with a Cathedral then disassemble its structure to produce a recipe for a next-generation Cathedral ... never having to settle for a helter skelter bazaar.
G
/pedantic tripe
next prev parent reply other threads:[~2016-07-15 1:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1264.1468397506.26859.help-gnu-emacs@gnu.org>
2016-07-13 21:37 ` Define skeleton from alist? Gene
2016-07-14 1:12 ` Paul Rankin
[not found] ` <mailman.1366.1468458751.26859.help-gnu-emacs@gnu.org>
2016-07-15 1:13 ` Gene [this message]
2016-07-13 8:11 Paul Rankin
2016-07-14 2:38 ` John Mastro
2016-07-14 6:00 ` Paul Rankin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c55a19ed-7d3b-4ac1-a331-38044179be8b@googlegroups.com \
--to=gene.sullivan@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.