Jack wrote:
>>The with-english-grammar macro has access to the super-form of
>>(from source) and (to destination) and can make the necesarray
>>modifications.

<snip>
> Why not just defun or defmethod unzip and unzipped? That doesn't give
> me any more flexibility.
> Given the paraphrase, I can call any of the following:
> (unzip (files-listed-in ticket) (from source))
> (unzip (from source) (files-listed-in ticket))

> ....
> (unzipped (files-listed-in ticket) (from source) (to target))
> ....
> And any permutation or combination.
> ....

> Where I don't need full-blown paraphrasing, I can (elide-cue cue) to
> give me the semantic cues in the code without affecting the result.

> Why not just use keywords? Because, as I have shown in another post in
> this thread
> (http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/8a4b3...),
> using keywords with the desired semantic cues can make the code less
> readable somewhere else (i.e., in the function definition).

>>(with-english-grammar
>>  (move-object (to destination) (from source)))

>>The with-english-grammar macro has access to the super-form of
>>(from source) and (to destination) and can make the necesarray
>>modifications.

> Why don't I just go all the way and write a full-blown English
> syntactic and semantic parser? That's not the point here. I merely want
> to make Lisp more readable for my purposes.

> WITH-ENGLISH-GRAMMAR could be used to isolate a set of cues from the
> rest of the package, but is it necessary now that I have defined it
> without flubbing the example? I don't see otherwise wanting to define a
> preposition as a function name. A package would isolate sufficiently
> the few symbols I would necessarily use as cues.

> Why not just use defun or defmacro for all of these permutations and
> computations? Why indeed! Paraphrasing, as I have described it,
> provides a new mechanism which allows arbitrary ordering of arguments
> which the author defined explicitly yet arbitrarily. It might not gel
> with formal mathematical notation, but we already have plenty of
> programming languages that define specifications for defining
> specifications so restrictively.

>>Lisp already has a construct that serves exactly that purpose -- keyword
>>arguments.  Combined with the package system, you can define your own
>>version of any existing function or macro:

>>(defpackage :cl-keyworded
>>  (:use) ;not using COMMON-LISP!
>>  (:export setf let))

>>(in-package :cl-keyworded)

>>(cl:defmacro setf (cl:&rest args)
>>  `(cl:setf
>>    ,@(cl:loop :for cons :on args :by #'cl:cdddr
>>               :do (cl:assert (cl:eq (cl:second cons) :to))
>>               :collect (cl:first cons) :collect (cl:third cons))))

>>(cl:defmacro let (bindings cl:&body body)
>>  `(cl:let ,(cl:loop :for (symbol cl:&key be) :in bindings

>                       :collect (cl:list symbol be))

>>     ,@body))

> Your example here is interesting and clearly shows a different way to
> do it than what I had envisioned. If I understand it correctly, you're
> suggesting that cl-keworded:let would be used as follows:

> (let ((foo :be bar))
>   ...)

> which would expand to

> (cl:let ((foo bar))
>   ...)

> I could live with it, though I might have tried something to allow me
> to do as follows:

> (where ((ticket is a new instance of 'ticket)
>         (document is "opus.sxw")
>         (path is "target/path"))
>   ...
>   (unzip (files-listed-in ticket) (from document) (to path)))

> --> (cl:let ((foo bar) (baz goop)...) ...)

> BUT that doesn't use lispy keyword-syntax conventions, and here I've
> stepped closer to natural language parsing. I'm not trying to modify
> Lisp quite that much.

> I could do as follows:

> (defmacro elide-cue (cue)
>   `(defmacro ,cue (form)
>      form)

> (elide-cue be)

> (let ((ticket (be (make-instance 'ticket)))
>       (document (be "opus.sxw))
>       ...)
>   ...)

> It seems much simpler than wrestling with redefitions of LET and any
> other form I want to bandage.

>>And I could not disagree with you more.  LOOP is *the* worst construct
>>in the Common Lisp language, because it disregards everything that's
>>good about computer programming.  Worse still, because LOOP's syntax is
>>completely different from *the rest of Lisp*, I don't get
>>autocompletion, indenting, or any other computer assistance.  So I have
>>to parse its meaning, token by token, by hand.

> LOOP is a domain-specific language. Why shouldn't it have its own
> syntax?