[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Define skeleton from alist?
Re: Define skeleton from alist?
Thu, 14 Jul 2016 18:13:09 -0700 (PDT)
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
> > 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
"Skeletons are an shorthand extension to the Lisp language, where various atoms
directly perform either actions on the current buffer or rudimentary flow
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
(sentence-end ". ")
(word-delimiter " ")
(split-string ; the inverse of mapconcat
; 'identity ; FUNCTION ; this argument is needed by mapconcat, though not
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
(mapconcat ; the inverse of split-string when both use mutually-compatible
'identity ; FUNCTION used to concatenate substrings into larger,
synthesized, composited strings
list-of-words ; SEQUENCE
word-delimiter ; SEPARATOR
(list) ; to be replaced via (mapcar (lambda mapconcat)) FUNCTIONAL construct
by those following the demo-cum-exercise
(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
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
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.
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.