Note the repeated reset of a variable. I don't want that. I want to avoid mutable variables; it's bad in functional programing. So, one should do like this:
But that has several problems. It's hard to debug. Also, in conventional lisp code formatting, “emacs-lisp-mode” would format it like this (expand your window width to prevent line wrapping):
If lisp has adopted its early concept of M-expression as syntax wrapper, then it could be written like this using a postfix syntax like unix's pipe |. Here, i show it using Mathematica syntax:
Note that in functional languages (e.g. Haskell, OCaml), they have both prefix and postfix operators. Usually the space character is used as context-sensitive implicit prefix operator. e.g. f x means “f” applied to “x”, and f a b c means (((f a) b) c). In Ruby, Perl, usually they have postfix operator desguised as calling object's methods. In perl, it's ->, in Ruby, it's just a dot ..
For detail, see:
The Concepts and Confusions of Prefix, Infix, Postfix and Fully Nested Notations Unix Pipe As Functional Language Programing Language: A Ruby Illustration of Lisp Problems
Also note, that even Haskell and OCaml support postfix and prefix syntax, but their syntax is a syntax soup. That is, it's one bunch of ad hoc designs with no consistancy, systematic grammar, or mathematical foundation. They are not much better than the syntax soup of C-like langs. The symbols are used promiscuously (see: Problems of Symbol Congestion in Computer Languages (ASCII Jam; Unicode; Fortress)) and the forms are idiosyncratic, e.g. i++, ++i, for(;;){}, while(){}, 0x123, expr1 ? expr2 : expr3, sprint(…%s…,…), …. The only language i know whose syntax approaches a systematic grammar is Mathematica. See: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Nested Notations and Math Notations, Computer Languages, and the “Form” in Formalism.
Piotr Chamera <piotr_cham...@poczta.onet.pl> writes:
> W dniu 2011-09-17 00:09, Xah Lee pisze:
>> Programing Language: LISP Syntax Problem of Piping Functions
> You can always cook a macro to simplify this.
> ; usage
> (sequential :x
> (+ 1 2)
> (* :x 5)
> (/ 23 :x))
If the OP ever gave more attention to what was written in cll than to
his own navel, he would have long know about such macros.
On Saturday, September 17, 2011 11:39:28 AM UTC+2, Piotr Chamera wrote:
> W dniu 2011-09-17 00:09, Xah Lee pisze:
> > Programing Language: LISP Syntax Problem of Piping Functions
> > Xah Lee, 2011-09-16
> > One of the annoying problem of the lisp nested syntax is the problem
> > of sequencing functions.
> > Here's a example i frequently encounter in emacs lisp. I like to
> > change a string in several ways. Example:
a decade ago, i didn't know lisp macro, but due to my admiration of
its Mathematica kinship and the grand-daddy of AI, i thought lisp
macros is a wonderful thing, powerful thing, a thing that allows one
to make arbitrary changes to the language's syntax on the fly.
today, i know, that lisp macros is the most motherfucking fuck in the
whole world of science in computer language.
which fuckhead invented lisp macros hack? I don't presume it's the
same guy who invented lisp. Anyone care to recite the history of lisp
macro?
without being knowledgeable of lisp macro history, my educated guess
is that its the forerunner that evolved into pattern matching proper a
la Mathematica.
Xah Lee <xah...@gmail.com> writes:
> a decade ago, i didn't know lisp macro, but due to my admiration of
> its Mathematica kinship and the grand-daddy of AI, i thought lisp
> macros is a wonderful thing, powerful thing, a thing that allows one
> to make arbitrary changes to the language's syntax on the fly.
Nonsense. You can't change the reader syntax. Whether or not you are
using macros, the expressions you evaluate are read in completely
first. Macros don't change the syntax but rather the evaluation order.
> today, i know, that lisp macros is the most motherfucking fuck in the
> whole world of science in computer language.
> which fuckhead invented lisp macros hack? I don't presume it's the
> same guy who invented lisp. Anyone care to recite the history of lisp
> macro?
What problem do you have? It is a rather basic concept easily
implemented. The typical evaluator can be written (omitting the error
cases) as
The last two lines are all that it takes to implement macros vs
functions.
That's much more straightforward than backquotes which are often
convenient (but not required) in connection with macros.
> without being knowledgeable of lisp macro history, my educated guess
> is that its the forerunner that evolved into pattern matching proper a
> la Mathematica.
What would make this an "educated guess"? I can see no connection with
pattern matching whatsoever.
David Kastrup <d...@gnu.org> writes:
> Xah Lee <xah...@gmail.com> writes:
>> without being knowledgeable of lisp macro history, my educated guess
>> is that its the forerunner that evolved into pattern matching proper a
>> la Mathematica.
> What would make this an "educated guess"? I can see no connection with
> pattern matching whatsoever.
A better question would be "What education?"
Specifically, "What education Xah Lee ever received?"
> without being knowledgeable of lisp macro history, my educated guess
> is that its the forerunner that evolved into pattern matching proper a
> la Mathematica.
No: macros have nothing to do with pattern matching. Obviously you don't understand them at all.
I'd argue, despite all this, that if you want to do this kind of point
free, pipe ish programming,
you should just refactor your code, because your packing too much
information into
too much space, and, just like pipe-heavy bash scripts, no one is
going to want to read
them later.
On Sunday, September 18, 2011 1:48:50 PM UTC+2, Tim Bradshaw wrote: > On 2011-09-18 07:14:29 +0100, Xah Lee said:
> > without being knowledgeable of lisp macro history, my educated guess > > is that its the forerunner that evolved into pattern matching proper a > > la Mathematica.
> No: macros have nothing to do with pattern matching. Obviously you > don't understand them at all.
But macros are very useful if you want to build pattern matching. Another thing that was not understood. :)
On Sep 18, 3:19 pm, Xah Lee <xah...@gmail.com> wrote:
> On Sep 17, 11:14 pm, Xah Lee <xah...@gmail.com> wrote:
> > which fuckhead invented lisp macros hack? I don't presume it's the
> > same guy who invented lisp. Anyone care to recite the history of lisp
> > macro?
Xah Lee <xah...@gmail.com> writes: > On Sep 18, 3:19 pm, Xah Lee <xah...@gmail.com> wrote: >> On Sep 17, 11:14 pm, Xah Lee <xah...@gmail.com> wrote:
>> > which fuckhead invented lisp macros hack? I don't presume it's the >> > same guy who invented lisp. Anyone care to recite the history of lisp >> > macro?
On 2011-09-18 21:03:02 +0100, Marco Antoniotti said:
> But macros are very useful if you want to build pattern matching.
> Another thing that was not understood. :)
Yes, and you can also a macro system which uses pattern matching (I don't really understand Scheme's macro system, but they seem to be at least partly pattern-based). But the two concepts are orthoganal.
> Yes, and you can also a macro system which uses pattern matching (I > don't really understand Scheme's macro system, but they seem to be at > least partly pattern-based). But the two concepts are orthoganal.
PS I'm not disagreeing with the article I'm responding to, it just looks that way!
On Monday, September 19, 2011 11:56:24 AM UTC+2, Tim Bradshaw wrote:
> On 2011-09-19 10:52:58 +0100, Tim Bradshaw said:
> > Yes, and you can also a macro system which uses pattern matching (I > > don't really understand Scheme's macro system, but they seem to be at > > least partly pattern-based). But the two concepts are orthoganal.
> PS I'm not disagreeing with the article I'm responding to, it just > looks that way!
The way it looks, Bradshaw, is that it's a chicken-n-egg thingy that the some people don't get :) :)
>> Xah Lee<xah...@gmail.com> writes:
>>> without being knowledgeable of lisp macro history, my educated guess
>>> is that its the forerunner that evolved into pattern matching proper a
>>> la Mathematica.
>> What would make this an "educated guess"? I can see no connection with
>> pattern matching whatsoever.
> A better question would be "What education?"
> Specifically, "What education Xah Lee ever received?"
Well -- perhaps the poster is referring to the fact that the parameter list of a macro is sort of pattern matched with the actual argument SEXP, which behaviour has been duplicated for the programmer in the DESTRUCTURING-BIND.
> Note the repeated reset of a variable. I don't want that. I want to
> avoid mutable variables; it's bad in functional programing. So, one
> should do like this:
> But that has several problems. It's hard to debug. Also, in
> conventional lisp code formatting, “emacs-lisp-mode” would format it
> like this (expand your window width to prevent line wrapping):
> If lisp has adopted its early concept of M-expression as syntax
> wrapper, then it could be written like this using a postfix syntax
> like unix's pipe |. Here, i show it using Mathematica syntax:
> Note the repeated reset of a variable. I don't want that. I want to
> avoid mutable variables; it's bad in functional programing. So, one
> should do like this:
> But that has several problems. It's hard to debug. Also, in
> conventional lisp code formatting, “emacs-lisp-mode” would format it
> like this (expand your window width to prevent line wrapping):
> If lisp has adopted its early concept of M-expression as syntax
> wrapper, then it could be written like this using a postfix syntax
> like unix's pipe |. Here, i show it using Mathematica syntax:
> Note that in functional languages (e.g. Haskell, OCaml), they have
> both prefix and postfix operators. Usually the space character is used
> as context-sensitive implicit prefix operator. e.g. f x means “f”
> applied to “x”, and f a b c means (((f a) b) c). In Ruby, Perl,
> usually they have postfix operator desguised as calling object's
> methods. In perl, it's ->, in Ruby, it's just a dot ..
> For detail, see:
> The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> Nested Notations
> Unix Pipe As Functional Language
> Programing Language: A Ruby Illustration of Lisp Problems
> Also note, that even Haskell and OCaml support postfix and prefix
> syntax, but their syntax is a syntax soup. That is, it's one bunch of
> ad hoc designs with no consistancy, systematic grammar, or
> mathematical foundation. They are not much better than the syntax soup
> of C-like langs. The symbols are used promiscuously (see: Problems of
> Symbol Congestion in Computer Languages (ASCII Jam; Unicode;
> Fortress)) and the forms are idiosyncratic, e.g. i++, ++i, for(;;){},
> while(){}, 0x123, expr1 ? expr2 : expr3, sprint(…%s…,…), …. The only
> language i know whose syntax approaches a systematic grammar is
> Mathematica. See: The Concepts and Confusions of Prefix, Infix,
> Postfix and Fully Nested Notations and Math Notations, Computer
> Languages, and the “Form” in Formalism.
> Xah
I've got math function composition (o f g etc) and argument lifting (^ + 1) in my personal Scheme lib. With them, instead of writing, say:
(string-prepend " Call me no more!!!"
(replace "this" "that"
(replace "You" "I do"
(replace "?" ", I do"
"this is right?! You think so?!"))))
I write
((o (^ string-prepend " Call me no more!!!")
(^ replace "this" "that")
(^ replace "You" "I do")
(^ replace "?" ", You"))
"this is right?! You think so?!")
or
(define replaces
(o (^ string-prepend " Call me no more!!!")
(^ replace "this" "that")
(^ replace "You" "I do")
(^ replace "?" ", You")))
(replaces phrase)
all evaluating to: "that is right, I do! I do think so, I do! Call me no more!!!"
Notice the chain of functions are put in the very same order they are normally called.
