[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Define skeleton from alist?

From: Gene
Subject: Re: Define skeleton from alist?
Date: Thu, 14 Jul 2016 18:13:09 -0700 (PDT)
User-agent: G2/1.0

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 
"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 
 (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

   (lambda (sentence)
    (lambda (list-of-words)
     (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 -- 
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.


/pedantic tripe

reply via email to

[Prev in Thread] Current Thread [Next in Thread]