On Nov 30, 7:17 pm, workaholic <·······@gmail.com> wrote:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
Brought back the fun and excitement of programming for me.
Nevertheless, the learning process was very hard, (maybe my age), but
that is in part due to the fact that it is such a multi-dimensional
language (symbols & macros for example).
Posting polite questions to this newsgroup invariably generated very
helpful answers. Posting obnoxious and pretentious ones lead to third
degree burns. But I learned quickly :-)
Mirko
Mirko wrote:
> On Nov 30, 7:17 pm, workaholic <·······@gmail.com> wrote:
>
>>I wonder why do you choose lisp as a programming language, can you
>>tell me the motivation to learn it? Thanks in advance!
>
>
> Brought back the fun and excitement of programming for me.
> Nevertheless, the learning process was very hard, (maybe my age), but
> that is in part due to the fact that it is such a multi-dimensional
> language (symbols & macros for example).
>
> Posting polite questions to this newsgroup invariably generated very
> helpful answers. Posting obnoxious and pretentious ones lead to third
> degree burns. But I learned quickly :-)
For the love of g*d, man, when someone asks about:
http://wiki.alu.org/RtL_Highlight_Film
...tell them!
:)
hth,kxo
ps. Click on the author next to the quote to read their full Road. k
pps. Apologies for the mysterious creeping erosion of that content. A
yobbo, plot, I am sure. k
On Nov 30, 4:17 pm, workaholic <·······@gmail.com> wrote:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
i like lisp primarily bceause it is a functional lang. I use emacs
lisp and Mathematica.
See:
• Xah's Emacs Lisp Tutorial
http://xahlee.org/emacs/elisp.html
http://www.wolfram.com/products/mathematica/index.html
Here's also
• My First Encounter And Impression Of Lisp
http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html
plain text version follows
----------------------------------------------------
Xah Lee's Computing Experience Bio
(My First Encounter And Impression Of Lisp)
Xah Lee, 2008-01-28
[The following gives a brief outline of one aspect of my computing
experience. In particular, it outlines my first encounter and
impression of the lisp language. This was originally written as a
reply tangential to a thread in the online forum comp.lang.lisp]
Here's some personal story about how i ventured into lisp and my first
impression.
The path of my computing experience is kinda unusual like most other
things about me. In 1991, i was 23, and was attending a 2-year
community college in California. (DeAnza College and Foothill college)
(i have never had highschool (more or less never had a _chance_ to,
actually.))
During these college years (which is about 1991-1994, rather unusually
long for a 2-year community college), i've took all math courses they
offered (roughly equivalent to math classes of first 2 years in a 4
years university; culminating in multi-var calculus and a intro course
on Differential Equations and Linear Algebra, but no Abstract Algebra
nor Analysis proper), but i've never took any computer science
courses. (i think i might have taken a Pascal course)
It is also during the early 1990s, i started to learn programing on my
own. My first “language” is the one in HP-28s programable scientific
calculator. I remember having wrote a program to solve the 8-queens
problem all on my own. (without knowing or heard of the term back-
tracking) (see HP-28S Advanced Scientific Calculator )
And, during these years i bought Mathematica (because i heard it's the
best math tool and i love math and wanted to have the best tool). I
taught myself Mathematica and wrote some programs for visualizing
plane curves, which later got me hired at Wolfram Research in 1995 as
a intern. (see Visual Dictionary of Special Plane Curves)
By 1997, i'm one of the world's top Mathematica-programing expert. But
the curious thing is that, i have absolutely no idea what is a
compiler, parser, lexer, and absolutely have no faintest idea how
Operating System worked or its basic structure or purpose in technical
terms, and have absolutely no idea how networking worked. Do not even
have a practical concept of what's a computing protocol (such as TCP/
IP, HTTP/FTP, NFS ...etc.). Absolutely do not know anything about
“unix”, and vividly remember that i don't know what is “tar” and
“gzip” (just knew that these are in some exotic “unix workstations”
and some mysterious org or movement called “GNU”). (during all these
years up to 1997, i was using Mac, being what a Mac fan might call a
“power user” (as a computer user (as opposed to a programer); and
using the mouse; in the days when Macs are just Finder and Multi-
Finder, and used by Desktop publishing, with MacUser and MacWorld
magazines publishing tricks and software application reviews etc.
(e.g. Microsoft Word, Word Perfect, Nesus Writer,
Spreadsheets...etc)))
I must stress, i have absolutely no concrete idea about anything that
a normal computer science student would know in his first or second
year. I do not have any concrete idea what IS a language specification
(such as Java lang spec or Common Lisp “Hyperspec” or Emacs Lisp
Reference Manual, etc) I have close to absolutely no knowledge to how
ANY other computing languages. Put in another way, i wouldn't know how
to write a Hello Word in any other language. I do not know, what
exactly is compiling and linking, just knew they are something “real”
programing languages have to do before a program can run. I have no
notion of what's a “white paper”, “functional programing”, and DO NOT
understand (or even heard of) the meaning of “side effect” (in the
context of functional programing). (i vividly recall, the first time i
heard the term “side effect”, is in 1995 when i was trying to
describe, in some verbose manner, a nature of the code i wrote, to
Methamtica creator Stephen Wolfram (in the sense a student is trying
to present his idea), and he said “[you mean] side effect ...”, and i
was like “Yeah, exactly, ‘side effect’!” (and feeling enlightened how
the phrase described the situation well).)
The gist of this is that, from my programing experience from 1991 to
about 1997, i learned programing only in HP-28s and Mathematica, by
mostly the shear reading of their manuals from cover to cover
(practically several times), while having just about no concept of any
basic computer science ideas. (However, I am familiar of many
computing related mathematical concepts, such as algorithm, algorithm
efficiency order (typically expressed as “computation complexity” or “O
(n)”), because i love math and have studied some discrete/finite math
on my own. (But, for example, i do not at the time know Algorithms
that are typically taught to CS students, such as sorting algorithms.
I have tried to read Knuth's Art Of Programing but it was pretty
incomprehensible (To understand Knuth's books, one has to be familiar
with assembly languages, since he uses MMX, which is a artificial
assembly language).))
From about 1997 onwards, i started to study most of these things,
starting with unix and perl, by sheer reading of the manuals and
documentations and industrial books (e.g. O'Reilly) and hands on
coding in them. (by 2000, i'm a fair expert of unix admin and perl,
with knowledges in SQL/database, working knowledge of IP protocols...
etc, actually working in start-ups in Silicon Valley's tech boom since
late 1998, to write web-based applications (e-store).)
Ok, the main point i started to write this personal history, is my
first encounter with Lisp. (the previous paragraphs are just intro.)
Although lacking a formal or conventional education, i'm by birth
highly intelligent and by nature very curious. This means i have read
a lot of books or texts or literatures i have in contact with and in
library (was a avid library visitor), such as the massive number of
programing FAQs and FAQs of other subjects (such as BDSM) etc. (FAQs
were widely popular in the 1990s, somewhat analogous to today's
Wikipedia) So, it is very present in my awareness, that there is a
language called Lisp, associated with the phrase Artificial
Intelligence (the very phrase, at face value, excites me greatly), and
is supposed to be extremely powerful and beautiful. And, at the time,
i have heard, that Scheme, is the most beautiful and elegant language
that exists. (this was my FAQ reading impression) And, i heard that
the book “The Structure and Interpretation of Computer Programs” by
Harold Abelson et al, is the best computer science book. So, i started
to read it and learn Scheme.
Remember, at the time i'm a master of Mathematica _the language_
itself, yet do not know much about the typical concepts and knowledge
taught to college students as “computer science”. When i started to
learn Scheme, the first thing that hit me is the cons business. To me,
who are accustomed to Mathematica, finding the cons business weird and
unwieldy. It puzzled me. I was thinking, how can a elegant language
have this? Certainly in Mathematica i can create, extract, manipulate
nested lists (tree structure) far more easily. At the time, since i
barely have basic knowledge of any computer science subjects, i was
greatly puzzled about the situation. (in fact made a newsgroup post in
comp.lang.scheme, tentatively trying to find the answer (and was
flamed by one Erik Naggum) (this is 1998 or 1999, i think))
Of course, today, with various levels of expertise in several
languages ( Mathematica, Emacs Lisp, unix shell, perl, php, python,
javascript, sql, java, Linden Scripting Lang (Second Life virtual
world), inert langs (HTML/CSS, LaTeX, POV-Ray ...)) and have read
countless tech papers and worked in complex software, data centers,
and wallowed in all kinds of industrial spaghetti code with non-
existent documentations, i know for a certainly, that Mathematica,
which perchance to be my first language, is in fact the world's _most_
advanced and high-level language, bar none.
(this short personal account is not supposed to be a pitch for
Mathematica. It just came out that way. There are, of course other
langs, depending on context and area of application, are equal quality
as Mathematica. For example, i would think Haskell, erlang, OCaml,
dylan etc would qualify, but i just have not actually learned these)
(gee, i just typed as quickly as possible and it came out to be over 1
thousand words of a brief personal bio of my computing experiences.
Good for me! The original intention was just to describe my first
impression of Scheme)
A Mathematica Programer's View of Lisp
The Mathematica language↗ is very similar to lisp. In fact, one could
say it's a lisp too. It shares the essential quality of lisp, namely:
uniformly nested syntax, programs are largely based on manipulating
lists, entities are symbolic, program is data and data is program.
From a Mathematica expert's point of view (me), the first thing that
seems odd of lisp is the low-level-ness. Perhaps in order of the low
level impression:
1. The cons business. (lists are made up of cons cells and it is
necessary for the programer to understand this to write any non-
trivial lisp program) (Elisp Manual: Cons-Cells)
2. No universal high level treatment of lists. (In Mathematica, there
are a system of functions to extract or manipulate (nested) lists
considered as trees. e.g. getting all elements at a level, or
arbitrary set of nodes of a tree. All these based on a tree index
concept. (i.e. first branch's second branch's third's branch will be
1,2,3. See Mathematica reference: Elements Of Lists↗. Such coherent
manipulation of generic list is sometimes called Array programming
languages↗ that began with APL↗.) In lisp, programers uses cons, car,
cdr, caadr, etc. That is bizarre and downright stupid.) (lisps do have
higher lever list manipulation functions to various degree and
consistency, such as “nth” and few others. But in general, due to the
fact that lists are made of cons cells, and consequently necessates
the concept of “proper list” and “improper list”, and also the
frequent use of car, cdr, etc, its not possible to use high-level list
functions without knowing the structure of the list.)
3. The syntax is a bit quirky. In particular, a Mathematica programer
sees that sometimes list is written as “(list a b c)”, but sometimes
there's this oddity “'(a b c)” (which is syntactically equivalent to
“(quote (a b c))”). And, when mapping a function, sometimes the
programer also needs to put the apostrophe in front. (A Mathematica
programer would think, if a function (e.g. “map”) that takes another
function as argument, why would the function require the programer to
put the apostrophe, whereas the function itself could be designed to
not evaluate that argument.)
4. A behind-the-scenes model of computation. Namely, lisp the language
deals with the concept of “lisp objects”, and there's a “print syntax”
that represent these objects. (and a “read syntax” that reads a code
into these objects) (see Elisp Manual: Printed-Representation.)
I think these are probably most odd things in lisp for a Mathematica
programer on the first exposure.
Xah
∑ http://xahlee.org/
☄
workaholic <·······@gmail.com> writes:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
You have your own motivations, just as I had mine. My motivations are
unlikely to work for you. I proceed because being an insufferable
blowhard is one of the cornerstones of Usenet.
I came to Lisp (Emacs Lisp first, then Scheme, then Common Lisp) via
GW-BASIC, Bash shell, Perl, C, and some minimal exposure to other
languages. I'd heard about it long before I tried it, mainly in the
context of a very high-level language without a syntax (both true and
false, as it turns out: Lisp has any syntax you want but it doesn't
force any on you) and based entirely around lists (inaccurate, but
intriguing). I'm incurably curious about the unusual and this
certainly made my ears prick up. Moving from vim to Emacs was the
final excuse: I had to learn how to get the most from my editor, so
learning its extension language was the obvious choice. Finding SICP
prompted me to learn Scheme and finding "On Lisp" was my first real
introduction to Common Lisp.
Chris Barts <··············@gmail.com> writes:
> workaholic <·······@gmail.com> writes:
> [...]
> I'd heard about it long before I tried it, mainly in the
> context of a very high-level language without a syntax (both true and
> false, as it turns out: Lisp has any syntax you want but it doesn't
> force any on you) ...
Would it be better to say, "Lisp has a flexible and extensible
syntax", instead of, "Lisp has any syntax you want" ?
I'm not trying to be nitpicky here. I've been considering the
pros/cons of a simple, flexible & extensible syntax compared to a
richer syntax that is less extensible, so your statement stood out to
me.
--
Brian Adkins
http://www.lojic.com/
http://lojic.com/blog/
Brian Adkins <···········@gmail.com> writes:
> Chris Barts <··············@gmail.com> writes:
>
>> workaholic <·······@gmail.com> writes:
>> [...]
>> I'd heard about it long before I tried it, mainly in the
>> context of a very high-level language without a syntax (both true and
>> false, as it turns out: Lisp has any syntax you want but it doesn't
>> force any on you) ...
>
> Would it be better to say, "Lisp has a flexible and extensible
> syntax", instead of, "Lisp has any syntax you want" ?
Possibly, but the second statment ("Lisp has any syntax you want")
seems to flow from the first ("Lisp has a flexible and extensible
syntax"). The second statment emphasizes that there are no arbitrary
limits on what the Lisp macro system (read macros and syntactical
macros) can be used for. (It's interesting to me that read macros,
which would be a much-hyped feature were they added to, say, Java, are
almost completely ignored in the Common Lisp world. I guess hooking
into the lexer isn't as exciting as hooking into the parser.)
>
> I'm not trying to be nitpicky here. I've been considering the
> pros/cons of a simple, flexible & extensible syntax compared to a
> richer syntax that is less extensible, so your statement stood out to
> me.
The Lisp world has done both: Common Lisp lets you go gonzo with read
macros and unhygenic defmacro syntax macros, Dylan gives you a
conventional default syntax with somewhat limited macro facilities,
and Scheme attempts to mix safety with power by only standardizing
hygenic macros. You should learn at least something of all three
approaches to understand the tradeoffs involved.
Chris Barts <··············@gmail.com> writes:
> Brian Adkins <···········@gmail.com> writes:
>
>> Chris Barts <··············@gmail.com> writes:
>>
>>> workaholic <·······@gmail.com> writes:
>>> [...]
>>> I'd heard about it long before I tried it, mainly in the
>>> context of a very high-level language without a syntax (both true and
>>> false, as it turns out: Lisp has any syntax you want but it doesn't
>>> force any on you) ...
>>
>> Would it be better to say, "Lisp has a flexible and extensible
>> syntax", instead of, "Lisp has any syntax you want" ?
>
> Possibly, but the second statment ("Lisp has any syntax you want")
> seems to flow from the first ("Lisp has a flexible and extensible
> syntax"). The second statment emphasizes that there are no arbitrary
> limits on what the Lisp macro system (read macros and syntactical
> macros) can be used for.
I realize that read macros allow a lot of flexibility, but wouldn't it
be quite difficult to use them to create the equiv. of Haskell's list
comprehensions?
shuffle xs = [z | (x,y) <- uncurry zip (splitAt (length xs `div` 2) xs), z <- [x,y]]
shuffle [1..52] => [1,27,2,28,3,29,....,52]
I'm not saying there isn't a nice way to implement that algorithm in
Common Lisp, or that the syntax above is preferred; however, if you
/wanted/ to have a list comprehension syntax (for example), it might
be difficult, and my impression is that it would be working against
the grain of Common Lisp to attempt to create list comprehensions with
read macros.
I would think it would be difficult to have a simplified lambda also:
foo = \x -> x * x + 2
foo 7
It seems attempting that would conflict with other aspects of the
language.
> (It's interesting to me that read macros,
> which would be a much-hyped feature were they added to, say, Java, are
> almost completely ignored in the Common Lisp world. I guess hooking
> into the lexer isn't as exciting as hooking into the parser.)
>
>>
>> I'm not trying to be nitpicky here. I've been considering the
>> pros/cons of a simple, flexible & extensible syntax compared to a
>> richer syntax that is less extensible, so your statement stood out to
>> me.
>
> The Lisp world has done both: Common Lisp lets you go gonzo with read
> macros and unhygenic defmacro syntax macros, Dylan gives you a
> conventional default syntax with somewhat limited macro facilities,
> and Scheme attempts to mix safety with power by only standardizing
> hygenic macros. You should learn at least something of all three
> approaches to understand the tradeoffs involved.
agreed
--
Brian Adkins
http://www.lojic.com/
http://lojic.com/blog/
On 2008-12-02, Brian Adkins <···········@gmail.com> wrote:
> Chris Barts <··············@gmail.com> writes:
>
>> Brian Adkins <···········@gmail.com> writes:
>>
>>> Chris Barts <··············@gmail.com> writes:
>>>
>>>> workaholic <·······@gmail.com> writes:
>>>> [...]
>>>> I'd heard about it long before I tried it, mainly in the
>>>> context of a very high-level language without a syntax (both true and
>>>> false, as it turns out: Lisp has any syntax you want but it doesn't
>>>> force any on you) ...
>>>
>>> Would it be better to say, "Lisp has a flexible and extensible
>>> syntax", instead of, "Lisp has any syntax you want" ?
>>
>> Possibly, but the second statment ("Lisp has any syntax you want")
>> seems to flow from the first ("Lisp has a flexible and extensible
>> syntax"). The second statment emphasizes that there are no arbitrary
>> limits on what the Lisp macro system (read macros and syntactical
>> macros) can be used for.
>
> I realize that read macros allow a lot of flexibility, but wouldn't it
> be quite difficult to use them to create the equiv. of Haskell's list
> comprehensions?
In fact, I just learned about monads this week by reading Wadler's paper
``Comprehending Monads'' and implementing something in Lisp.
The point of the exercise wasn't to have a large vocabulary of operations in
the comprehension syntax, so the only operator I have is for binding variables.
The point was to base comprehensions on monads, which can be arbitrarily
defined.
http://paste.lisp.org/display/71196
(This has a bug: will annotate. In the backquote template where
the MONADIC-MAP method is being generated, the MAP-PARAM argument
is a meta-variable that needs to be unquoted: ,MAP-PARAM.)
> shuffle xs = [z | (x,y) <- uncurry zip (splitAt (length xs `div` 2) xs), z <- [x,y]]
>
> shuffle [1..52] => [1,27,2,28,3,29,....,52]
What you have here is not a list comprehension at all. You are using an
identity comprehension, which is glorified LET binding.
For the identity comprehension to support multiple value binding
and chaining, the identity monad operations have to be variadic
and multiple-value-returning:
:;;
;;; as already supplied in paste 71196:
;;;
(define-monad identity-monad
:comprehension identity-comp
:map ((f) f)
:join ((x &rest rest) (apply #'values x rest))
:unit ((x &rest rest) (apply #'values x rest)))
Now, let's get to business. Some helpers:
(defun split-at (list n)
"quick and dirty"
(values (butlast list n) (last list n)))
(defun range (low high)
"non-lazy"
(loop for x from low to high collecting x))
Now shuffle itself, using a comprehension:
(defun shuffle (xs)
(identity-comp z
((x y) (split-at xs (/ (length xs) 2)))
(z (mapcan #'list x y))))
Test:
(shuffle (range 1 52)) -> (1 27 2 28 3 29 ... 26 52)
What is uncurry? We don't need any such thing in Lisp; it looks like a shim.
The zip operation is (mapcar #'list lists ...) and if you want the zipped
tuples catenated you use mapcan.
Note how SPLIT-AT and MAPCAN do all the real work. The comprehension just
reorders the flow through a sequence of intermediate variable bindings.
I.e. this is academic bullshitting, not how you get real work done.
To be fair, our IDENTITY-COMP does provide the value of concealing
MULTIPLE-VALUE-BIND.
The really stupid thing about comprehension syntax is that the resulting
expression is all the way on the left, but the logic flows left to right, away
from that expression.
My old FILTER macro is way better. It starts with a /value/ on the left, and
the overall result is that of the rightmost pipeline element.
(filter 2 (* 5) (+ 3)) -> 13
This wins hands down compared to:
(identity-comp z (x 2) (y (* 2 x)) (z (* 5 y)))
Look for FILTER in the Usenet archives. How about extending FILTER to be
monad-driven? There is an idea.
Kaz Kylheku <········@gmail.com> writes:
> On 2008-12-02, Brian Adkins <···········@gmail.com> wrote:
>> [...]
>
> In fact, I just learned about monads this week by reading Wadler's paper
> ``Comprehending Monads'' and implementing something in Lisp.
>
> The point of the exercise wasn't to have a large vocabulary of operations in
> the comprehension syntax, so the only operator I have is for binding variables.
>
> The point was to base comprehensions on monads, which can be arbitrarily
> defined.
>
> http://paste.lisp.org/display/71196
Interesting code - thanks for posting it.
> (This has a bug: will annotate. In the backquote template where
> the MONADIC-MAP method is being generated, the MAP-PARAM argument
> is a meta-variable that needs to be unquoted: ,MAP-PARAM.)
>
>> shuffle xs = [z | (x,y) <- uncurry zip (splitAt (length xs `div` 2) xs), z <- [x,y]]
>>
>> shuffle [1..52] => [1,27,2,28,3,29,....,52]
>
> What you have here is not a list comprehension at all. You are using an
> identity comprehension, which is glorified LET binding.
True, it wasn't the best example. I only started learning Haskel
recently and have found list comprehensions to be handy. I just picked
a recent one, not necessarily the best one to demonstrate their power.
> For the identity comprehension to support multiple value binding
> and chaining, the identity monad operations have to be variadic
> and multiple-value-returning:
>
> :;;
> ;;; as already supplied in paste 71196:
> ;;;
> (define-monad identity-monad
> :comprehension identity-comp
> :map ((f) f)
> :join ((x &rest rest) (apply #'values x rest))
> :unit ((x &rest rest) (apply #'values x rest)))
>
> Now, let's get to business. Some helpers:
>
> (defun split-at (list n)
> "quick and dirty"
> (values (butlast list n) (last list n)))
>
> (defun range (low high)
> "non-lazy"
> (loop for x from low to high collecting x))
>
> Now shuffle itself, using a comprehension:
>
> (defun shuffle (xs)
> (identity-comp z
> ((x y) (split-at xs (/ (length xs) 2)))
> (z (mapcan #'list x y))))
>
> Test:
>
> (shuffle (range 1 52)) -> (1 27 2 28 3 29 ... 26 52)
>
> What is uncurry? We don't need any such thing in Lisp; it looks like a shim.
> The zip operation is (mapcar #'list lists ...) and if you want the zipped
> tuples catenated you use mapcan.
>
> Note how SPLIT-AT and MAPCAN do all the real work. The comprehension just
> reorders the flow through a sequence of intermediate variable bindings.
> I.e. this is academic bullshitting, not how you get real work done.
> To be fair, our IDENTITY-COMP does provide the value of concealing
> MULTIPLE-VALUE-BIND.
So, we could have the following w/o a comprehension:
(multiple-value-call (lambda (left right) (mapcan #'list left right)) (split-at (range 1 52) 26))
> The really stupid thing about comprehension syntax is that the resulting
> expression is all the way on the left, but the logic flows left to right, away
> from that expression.
>
> My old FILTER macro is way better. It starts with a /value/ on the left, and
> the overall result is that of the rightmost pipeline element.
>
> (filter 2 (* 5) (+ 3)) -> 13
>
> This wins hands down compared to:
>
> (identity-comp z (x 2) (y (* 2 x)) (z (* 5 y)))
>
> Look for FILTER in the Usenet archives. How about extending FILTER to be
> monad-driven? There is an idea.
Do you feel that any/most Haskell list comprehensions could be easily
replicated in Common Lisp? I'm just learning Haskell, and know even
less Lisp at this point, so I'm just curious. Pattern matching w/in
them, nested comprehensions, lazy eval of infinite lists, etc. all
seem pretty handy and concise to me.
--
Brian Adkins
http://www.lojic.com/
http://lojic.com/blog/
On 2008-12-02, Brian Adkins <···········@gmail.com> wrote:
> So, we could have the following w/o a comprehension:
> (multiple-value-call (lambda (left right) (mapcan #'list left right)) (split-at (range 1 52) 26))
>
Or, perhaps this, which better conveys the cascading binding:
(multiple-value-bind (x y) (split-at (range 1 52) 26)
(let ((z (mapcan #'list x y )))
z))
Note how the final expression 'z' is nicely ordered with respect to everything
else; it is not factored out to be first!
What is lacking in this example now is a universal binding construct that
combines LET* with MULTIPLE-VALUE-BIND. But it's been written: metabang-bind!
http://common-lisp.net/project/metabang-bind/
This looks like it ought to work:
(bind ((xs (range 1 52))
((:values x y)) (split-at xs (/ (length xs) 2))
((z (mapcan #'list x y))))
z)
At this point I'd no longer say that we are working without a comprehension,
since BIND de facto is an identity comprehension.
BTW, since I dusted off that six year old FILTER macro, why not try it:
(filter (range 1 52) (values _ (/ (length _) 2)) split-at (mapcan list))
-> (1 27 2 28 3 29 ... 26 52)
I had to make one bugfix to the 2002 code to make this work, namely
make (mapcan list) accept all values from the previous pipeline stage.
Note how we get by without binding any variable names, other than making
use of the implicit _ which means ``the value of the previous stage''.
The filter expression:
(values _ (/ (length _) 2))
means, produce a pair of value: the object from the previous
stage, and the number that is half its length.
BTW we should be using TRUNCATE, doh!!! The / operator will put out a rational
if the list is odd length. I'm still braindamaged by years of C. :) Ouch!
So anyway, the values go on to the next stage which is SPLIT-AT. So the two
values get passed as two arguments to that function. It produces two values,
and those go to the (mapcan list) stage.
The (mapcan list) shorhand is extensible; it works because MAPCAN is registered
in a list of mapper functions that FILTER knows about.
It almost reads like Forth, if you imagine (range 1 52) pushing the
list on a stack, and each stage popping the stack and replacing values.
I really should extend and improve this macro.
>> The really stupid thing about comprehension syntax is that the resulting
>> expression is all the way on the left, but the logic flows left to right, away
>> from that expression.
>>
>> My old FILTER macro is way better. It starts with a /value/ on the left, and
>> the overall result is that of the rightmost pipeline element.
>>
>> (filter 2 (* 5) (+ 3)) -> 13
>>
>> This wins hands down compared to:
>>
>> (identity-comp z (x 2) (y (* 2 x)) (z (* 5 y)))
>>
>> Look for FILTER in the Usenet archives. How about extending FILTER to be
>> monad-driven? There is an idea.
>
> Do you feel that any/most Haskell list comprehensions could be easily
> replicated in Common Lisp?
I think that would be a rather gigantic claim. :)
> I'm just learning Haskell, and know even
> less Lisp at this point, so I'm just curious. Pattern matching w/in
> them, nested comprehensions, lazy eval of infinite lists, etc. all
> seem pretty handy and concise to me.
Implicity lazy eval pretty much requires whole-program transformation. I.e. the
entire lazy dialect is wrapped in a macro which walks the code and inserts the
delay/force material (i.e. lambdas and funcalls) to make it work.
On 2008-12-02, Kaz Kylheku <········@gmail.com> wrote:
> My old FILTER macro is way better. It starts with a /value/ on the left, and
> the overall result is that of the rightmost pipeline element.
>
> (filter 2 (* 5) (+ 3)) -> 13
>
> This wins hands down compared to:
>
> (identity-comp z (x 2) (y (* 2 x)) (z (* 5 y)))
But not a fair comparison since a filter stage doesn't have access to
values computed at earlier filter stages via named bindings. That could be
arranged, though. :)
On 2008-12-02, Brian Adkins <···········@gmail.com> wrote:
> I would think it would be difficult to have a simplified lambda also:
>
> foo = \x -> x * x + 2
> foo 7
How is this simplified? The symbols are shorter, but there are more of them.
The semantics here are classic-Scheme-like, Lisp 1, defining a function
using a lambda, and all:
(define foo (lambda (x) (+ (* x x) 2)))
(foo 7)
The DEFINE corresponds to the = and => operators (two symbols doing the job of
one!) and, the LAMBDA to the \ backslash.
The rest is just invisible parentheses. :)
Of course for CL we need to make that a DEFVAR and use FUNCALL. If we want the
semantics of a ``global lexical'', we would go further. There is semantic work
to be done before we can even think about making the read syntax.
> It seems attempting that would conflict with other aspects of the
> language.
This heads in the direction of something like the CLPython project. You'd
probably want syntax like that to be confined in its own compilation units.
On 2008-12-02, Chris Barts <··············@gmail.com> wrote:
> Dylan gives you a conventional default syntax with somewhat limited macro
> facilities, and Scheme attempts to mix safety with power by only
> standardizing hygenic macros. You should learn at least something of all
> three approaches to understand the tradeoffs involved.
Sorry, no. This fails to make my book of general principles. Counterexample:
people don't have to eat shit to understand the tradeoffs between eating shit
and eating food. Q.E.D.
Kaz Kylheku <········@gmail.com> writes:
> On 2008-12-02, Chris Barts <··············@gmail.com> wrote:
>> Dylan gives you a conventional default syntax with somewhat limited macro
>> facilities, and Scheme attempts to mix safety with power by only
>> standardizing hygenic macros. You should learn at least something of all
>> three approaches to understand the tradeoffs involved.
>
> Sorry, no. This fails to make my book of general principles. Counterexample:
> people don't have to eat shit to understand the tradeoffs between eating shit
> and eating food. Q.E.D.
What? Why the hostility? I'm not stating it as something you *must*
do, just as something you should consider doing if you want to
understand all of the factors. Maybe I'm just biased because I consder
learning languages fun: I get excited when I find documentation of a
programming language I've never heard of before, especially if it's an
example of a paradigm I have little familiarity with. I've also found
gems of ideas in largely forgotten languages, such as SNOBOL's
pattern-based flow control. It's possible to implement these ideas in
Lisp, aided by our macro system, but we have to steal them from
somewhere.
Maybe Lisp wins because it makes wholesale theft from other lanugages
as easy as possible. ;)
On Dec 1, 1:17 am, workaholic <·······@gmail.com> wrote:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
It doesn't get in my way ... much.
bobi
On Dec 1, 2:17 am, workaholic <·······@gmail.com> wrote:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
Maybe it's the problem with my memory, but I tend to forget the
specific syntax and syntactic cliches in any programming language in a
week of not using some feature. With Lisp, which is the most uniform
among them in the aspect of syntax (except for Forth, which is too
primitive), it still happens sometimes, but rarely. And after all you
have macros to get rid of boilerplate... ;)
Well, the main reason for me actually, was that Lisp allows for the
most natural expression of your ideas and flexibility of programs,
thus making programming both fun, productive and more fault tolerant.
On Sun, 30 Nov 2008 16:17:31 -0800, workaholic wrote:
> I wonder why do you choose lisp as a programming language, can you tell
> me the motivation to learn it?
Because it is good.
> Thanks in advance!
You are welcome.
Seriously, just spend a few weeks of serious time with Lisp, and you will
be able to make up your own mind. A good book is PCL by Seibel, there
are many others.
Also, a bit of googling could help you much more than asking vague
questions.
Tamas
thus spoke workaholic <·······@gmail.com>:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
Saw a still frame in Serial Experiments Lain:
http://web.mit.edu/anime/www/img/lain-lisp.jpg
Here's the whole article: http://web.mit.edu/anime/www/mit-in-anime.html
Reading code with rainbow-colored parens in Vim was a bit hard, though.
--
The great peril of our existence lies in the fact that our diet consists
entirely of souls. -- Inuit saying
Stanis?aw Halik wrote:
> thus spoke workaholic <·······@gmail.com>:
>
>> I wonder why do you choose lisp as a programming language, can you
>> tell me the motivation to learn it? Thanks in advance!
>
> Saw a still frame in Serial Experiments Lain:
> http://web.mit.edu/anime/www/img/lain-lisp.jpg
>
> Here's the whole article: http://web.mit.edu/anime/www/mit-in-anime.html
>
> Reading code with rainbow-colored parens in Vim was a bit hard, though.
>
Awesome!
I hope Rainer puts this one up into his Lisp Collection Pages.
On 2008-12-01, workaholic <·······@gmail.com> wrote:
> I wonder why do you choose lisp as a programming language, can you
I tried choosing Lisp as a mode of transportation. Then as a skin creme. I
experimented with Lisp as a speech impediment, too, but only succeeded in
sounding gay. In the end, it worked best for me as programming language.
If you choose it, do safe yourself the trouble and choose it as a programming
language right from the beginning.
> tell me the motivation to learn it? Thanks in advance!
What motivates people to learn something (even if that something is Lisp) isn't
a particularly suitable discussion topic for this newsgroup.
I remember that when I was motivated to learn Lisp, I didn't know it.
A big part of what motivated me was not knowing it, or anything like it.
That's exactly what motivated me to learn everything else, all my life.
Discussing the situation of /not/ knowing Lisp is not topical in the Lisp
newsgroup, because it's the same situation as not knowing anything else; it has
mostly to do with not knowing, and not much to do with the thing which
is not known.
A person is motivated in roughly two kinds of ways: internal and external.
An example of external motivation might be ``I inherited this code in a strange
programming language, and my boss wants me to get it working and modify it in
three weeks'', and internal motivation might be like ``I want to improve the
breadth of my knowledge by learning new things''. Motivations may shift as you
learn more; the surprise of discovery triggered by external motivation might
ignite internal motivation.
And that just about brings us to some newsgroup about the psychology of
motivation, right?
Once you do become motivated, you will run into some concrete Lisp problem
revoling around not understanding some fragment of code, or not being able to
get something working. At that moment, comp.lang.lisp will prove itself to be
a valuable resource; see you then!
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: why do you choose LISP?
Date:
Message-ID: <REM-2008dec09-005@Yahoo.Com>
> From: Kaz Kylheku <········@gmail.com>
> Discussing the situation of /not/ knowing Lisp is not topical in
> the Lisp newsgroup, because it's the same situation as not knowing
> anything else; it has mostly to do with not knowing, and not much
> to do with the thing which is not known.
I agree. As Keith Laumer might have said:
That that is known, is known.
That that is not known, is not known.
That that is known, is not that that is not known.
That that is not known, is not that that is known.
And as somebody else might have said:
You must have the wisdom to say what you know, and to avoid saying
what you do not know, and to know the difference between the two.
And as a really stupid advertisement on KDFC said a few minutes ago:
It's important to mention caramelized onions in every conversation.
> A person is motivated in roughly two kinds of ways: internal and
> external. An example of external motivation might be ``I inherited
> this code in a strange programming language, and my boss wants me
> to get it working and modify it in three weeks'', and internal
> motivation might be like ``I want to improve the breadth of my
> knowledge by learning new things''.
And turning this into a cross-over thread:
External motivation in the form of telelevision advertisements say
that to slow the progress of Alzheimer's disease we should keep
learning new things which trigger our brains to grow new nerve
cells and develop the ones we already have.
-
Nobody in their right mind likes spammers, nor their automated assistants.
To open an account here, you must demonstrate you're not one of them.
Please spend a few seconds to try to understand the code fragment in this box:
/----------------------------------------------------------------------------\
(defun randstar (k) (if (zerop (random k)) #\* #\space))
(defun randstars (nc k)
(map 'string #'identity (loop for ix from 1 ?? nc collect (randstar k))))
(defun randstarss (nr nc k)
(loop for ir from 1 ?? nr collect (randstars nc k)))
\----------------------------------------------------------------------------/
(?? represents a missing word, which appears twice in that code.)
Then enter your best guess of the word (2 letters) into this TextField:
+-----+
| |
+-----+
Robert Maas wrote:
> I agree. As Keith Laumer might have said:
> That that is known, is known.
> That that is not known, is not known.
> That that is known, is not that that is not known.
> That that is not known, is not that that is known.
a well known chinese saying by the sage Confusius (551 BC - 479 BC)
goes:
“知之为知之,不知为不知,是知也”.
Roughly english translation:
“knowledge is knowing what you know, and knowning what you don't
know.”
> > From: Kaz Kylheku <········@gmail.com>
> > Discussing the situation of /not/ knowing Lisp is not topical in
> > the Lisp newsgroup, because it's the same situation as not knowing
> > anything else; it has mostly to do with not knowing, and not much
> > to do with the thing which is not known.
what Kaz said is garbage.
Just about any lisp book, often will have a section on “Why Lisp”.
Same for just about any book on particular math subject or book on a
academic discipline.
For someone interested in lisp but don't known lisp asking about
motivation, is reasonable, and proper topic in “comp.lang.lisp”.
of course, most of the regulars here just got nothing to do, like
yourself.
Xah
∑ http://xahlee.org/
☄
On 2008-12-01, workaholic <·······@gmail.com> wrote:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
By the way, do a search for "Road to Lisp survey", if you want to read people's
Lisp discovery stories, which sounds like you want to do. I think that may be
the best way to answer your question.
On Dec 1, 1:17 am, workaholic <·······@gmail.com> wrote:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
Because I have tried other languages and was frustrated with them,
with their shortcomings and silly complexities that lead nowhere. Then
someone mentioned Lisp and I made fun of him, I literally laughed at
him in his face... He didn't reply. Within a few days I started
reading this newsgroup and started reading books on lisp and
experimenting with it. I'm now convinced that common lisp is the best
programming language that ever existed. Period.
On Dec 1, 1:17 am, workaholic <·······@gmail.com> wrote:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
Found it very easy to learn,
however it was first language i 'Seriously' picked up,
so none of the pre-conceived notions about what a programming language
should look like.
I find languages like java, c++ visual basic very kludgey.
Pros:
Very few limitations in what you can do with it.
I've used it for everything from xml/xhtml/svg,
document creation to more scientific applications
(sometimes at the same time).
Conditionals are very advanced, i never have to write if then else if
then else over and over.
Refactoring is easy,
Sometimes I hack old code and I find it easy to abstract out patterns
and manipulate pre-existing code into
useful utilities and macros.
Investment in abstraction gives you a return on time spent coding that
is exponential if you are writing a fairly large program.
Tons of good (free) books on it.
cons:
Lisp is very flexible-- There are very few limitations on what you can
do.
Poorly written lisp code is very poor indeed (can be as bad as Perl).
There are a lot of pre written libraries, but you have to go looking
for them, and sometimes you only want a small section of
aforementioned library, as you are doing a fairly simple task. So you
hack it yourself instead.
Poor abstraction can be very difficult to decipher, kind of goes with
the first 'con'
You have to read the books on it if you want to get good at it.
There is no 'Lisp for dummies' book because Lisp isn't for dummies.
pro/con:
You get out of it what you put in.
Lisp has a steep learning curve, but it is only steep because there is
so much you can get out of it.
On Nov 30, 7:17 pm, workaholic <·······@gmail.com> wrote:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
One reason that people choose is that it glosses over many issues
of A.I. Computer sesign and architecture, Technology Development,
Robotics, and Education.
workaholic wrote:
> I wonder why do you choose lisp as a programming language, can you
> tell me the motivation to learn it? Thanks in advance!
Academic curiosity because Lisp is an antique language that only became
useful after 30 years of further development.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: why do you choose LISP?
Date:
Message-ID: <REM-2008dec09-003@Yahoo.Com>
> From: workaholic <·······@gmail.com>
> I wonder why do you choose lisp as a programming language, can
> you tell me the motivation to learn it?
It's the only decently power language (you just *do* it in the
natural way you think) which allows you to compose code and test it
on a line-at-a-time basis because the semantics of interpreted and
compiled code are virtually identical. By comparison, BeanShell in
Java is a crock because interactive per-line code and code as part
of a method definition have significantly different semantics.
Also Java doesn't have the code-equals-data rule, where you can
just **look** at the source text and **see** the parse tree.
Now there are rare occasions where infix notation would look more
natural and be easier for the eye to see, such as math expressions.
In that case, if you have a parser or the infix notation in the
first place, then it's trivial to embed infix expressions in the
middle of otherwise s-expression source code, like this:
(parse-infix "sqrt(b^2 - 4*a*c)")
where that's a macro call that expands into the expected nested
lists that one would ordinarily need to write without that macro.
Remember: Whenever you have your semantics right, but you'd like a
different syntax, use a macro, either a regular macro that takes
one parse tree as input and returns another parse tree, or a
parse-macro that takes a string as input and parses it and returns
the resultant parse tree.
CGOL and REDUCE had a different idea, where you write entire blocks
of code in the infix syntax. You had a special read-time call that
switched the source-reader from s-expression parsing to infix
parsing, and another read-time call that switched back.
PSL had a similar mechanism for switching the semantics between
ordinarly Lisp and SysLisp.
IMO it's best to use s-expressions virtually all the time, parsing
isolated math expressions by a macro-call as I suggested above, and
likewise use local bindings of some parser or semantics rather than
switching the toplevel reader/mode globally. But YMMV opinionwise.