Hello folks,
I am asking for some help with Lisp propaganda.
Why should a programmer choose for Lisp, while there are also very
much other functional languages, like Clean, Haskell, of which the
syntax is very much more elegant (according to their users).
So: why Lisp and not another functional language?
I am asking this because I am in kind of a discussion about Lisp, what
it can do and express, with a teacher who uses preferably other
functional languages.
His most important critic on Lisp is that the syntax is so ugly
compared to the syntax of his language of choice (Amanda). The
uglyness of the Lisp syntax lies in the different quoting of functions
and constants and the strange ways of applying functions with funcall
and apply, while in his language these ugly syntactical constructs are
not necessary to do what is necessary.
Example:
Lisp:
(defun twice (fun)
(lambda (&rest args)
(apply fun
(apply fun args)
)))
Amanda:
double f = args -> f (f args)
Lisp:
(funcall (twice #'(lambda(x y) (list (* x y)(+ x y)))) 1 3)
Amanda:
double ((x,y) -> (x*y,x+y)) (1,3)
Please help me out :).
Michiel
··············@gmail.com (Michiel Borkent) wrote in message news:<····························@posting.google.com>...
> Hello folks,
>
> I am asking for some help with Lisp propaganda.
You need help with your very subject line, which insinuates that Lisp
is (only) a functional programming language. In fact, functional
programming is just a paradigm that is supported by Lisp. One large
benefit of Lisp is that it's not restricted to that paradigm.
> Why should a programmer choose for Lisp, while there are also very
> much other functional languages, like Clean, Haskell, of which the
> syntax is very much more elegant (according to their users).
Because, for one thing, these are not really languages but software
packages defined by a small handful of freeware implementations. They
have no ISO or ANSI standard. I can't go to a vendor and buy a
compiler for these things.
The claims about elegant syntax are only an opinion about esthetics,
which ignore technical issues.
One can make esthetic arguments in favor of the syntax of Haskell, and
one can make esthetic arguments in favor of Lisp syntax. But one can
also make technical arguments for Lisp syntax.
Syntax like that of Haskell and whatnot cannot be defended on
technical grounds. It doesn't serve a functional requirement, whereas
that of Lisp does serve a functional requirements.
> So: why Lisp and not another functional language?
>
> I am asking this because I am in kind of a discussion about Lisp, what
> it can do and express, with a teacher who uses preferably other
> functional languages.
All the teachers I ever had are still teachers, while I earn big bucks
writing real software.
I would take C++ over crap like Clean or Haskell, because I can use
C++ to engineer myself into something better.
> His most important critic on Lisp is that the syntax is so ugly
> compared to the syntax of his language of choice (Amanda).
I would say that his esthetics are misplaced. How does this man dress?
Does he have a fit body? What car does he drive? Where does he live
and how is his place furnished? What does his wife or girlfriend look
like?
If you are going to talk about superficial fluff like ugly versus
pretty, these are the areas where they matter.
If you are concerned about image, then the most rational thing to do
is to make the most money by programming so you can afford it.
If writing and delivering an application written in Haskell is how you
can do that, then by all means.
The
> uglyness of the Lisp syntax lies in the different quoting of functions
> and constants and the strange ways of applying functions with funcall
> and apply, while in his language these ugly syntactical constructs are
> not necessary to do what is necessary.
Applicators like FUNCALL, APPLY, MAPCAR, and others all do different
jobs. You can't use the same syntax for all of them.
That is to say, for at most one of the application operations can you
have a syntax that is denoted by the absence of an operator keyword.
This is the gripe that some nutcases have with LIsp: that the FUNCALL
operation has a visible operator:
(funcall <function-object> arguments ...)
rather than just
(<function-object> arguments ...)
But even if you had this latter syntax, you'd still have to have some
way of distinguishing yourself if you want the semantics of APPLY or
other variations.
> ...) rather than just (<function-object>
In fact you do have this syntax when <function-object> is denoted by a
lambda expression written right there.
The reason that this syntax cannot be generalized is that most of the
time, you have a variable to which a function object is bound, and so
then your syntax becomes
(some-symbol arguments ...)
Lisp has a double namespace: a symbol has a function binding and a
value binding. So this syntax is ambiguous. Do you use the function
object that is bound as a value to SOME-SYMBOL or do you use the
function definition for SOME-SYMBOL?
> Example:
>
> Lisp:
>
> (defun twice (fun)
> (lambda (&rest args)
> (apply fun
> (apply fun args)
> )))
>
> Amanda:
>
> double f = args -> f (f args)
I can't read this syntax without looking up the reference manual for
Amanda which will tell me the relative precedence of these infix
operators.
I don't understand how the one argument case is distinguished from the
argument list. How does the compiler know that this is a
multi-argument function? Is ``args'' a reserved keyword meaning ``zero
or more arguments''?
If I have three lists, A, B, and C, how do I write an Amanda function
call such that the elements of these lists become individual
arguments? That is to say, how do you translate these two into Amanda?
(funcall f a b c) ;; pass the lists as three objects
(apply f a b c) ;; blow up the lists into arguments to f
How can we possibly achieve both semantics in one syntax:
(f a b c) ;; apply or funcall? read programmer's mind.
> Lisp:
>
> (funcall (twice #'(lambda(x y) (list (* x y)(+ x y)))) 1 3)
>
> Amanda:
>
> double ((x,y) -> (x*y,x+y)) (1,3)
What is this ``double'' stupidity that has to be repeated?
What does x*y,x+y mean? Is it x * (y,x) + y?
> Please help me out :).
I don't see how the two examples are the same. The TWICE function
returns a function object, whereas double seems to just do the
operation.
Are you sure that the Lisp equivalent should not just be:
(defun double (f &rest args)
(apply f (apply f args))
(double (lambda (x y) (list (* x y) (+ x y))) 1 3)
This seems to be closer to the Amanda thing:
double f = args -> f (f args)
double ((x,y) -> (x*y,x+y)) (1,3)
No? But at what readability and possible efficiency cost. For one
thing, in Lisp we have multiple return values; we would not be using
apply with lists to do this kind of thing. The first instinct would be
to not even use variadic functions, but rather something like this:
(defun double (f x y)
(multiple-value-call f (funcall f x y))
This means that we have a function F that takes two arguments, and
produces two values. The DOUBLE function takes two values, feeds them
to F, and then takes the two return values and feeds them as arguments
to F again. There are some standard functions that take two args and
return two values, such as TRUNCATE. For example (TRUNCATE 30 7)
returns 4 2, and (TRUNCATE 3 4) returns 2 0. We could express this
with the above DOUBLE:
(double #'truncate 30 7) --> 2 0
How do you express the semantic difference between lists and multiple
values in Amanda?
Again, I don't see how you can read the programmer's mind.
MULTIPLE-VALUE-CALL is different from APPLY, which is different from
FUNCALL, etc. To try to merge them all together is an engineering
mistake, because then you end up treating all function arguments and
return values as a list data structure.
<···@ashi.footprints.net> wrote:
>If I have three lists, A, B, and C, how do I write an Amanda function
>call such that the elements of these lists become individual
>arguments? That is to say, how do you translate these two into Amanda?
>
> (funcall f a b c) ;; pass the lists as three objects
> (apply f a b c) ;; blow up the lists into arguments to f
Only the last argument to apply is flattened.
CL-USER> (apply #'list '(a b) '(c d) '(e f))
((A B) (C D) E F)
--
Juho Snellman
"Premature profiling is the root of all evil."
From: Antonio Menezes Leitao
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <87lley38k6.fsf@evaluator.pt>
··············@gmail.com (Michiel Borkent) writes:
> His most important critic on Lisp is that the syntax is so ugly
> compared to the syntax of his language of choice (Amanda). The
> uglyness of the Lisp syntax lies in the different quoting of functions
> and constants and the strange ways of applying functions with funcall
> and apply, while in his language these ugly syntactical constructs are
> not necessary to do what is necessary.
Can your teacher use macros in Amanda? Maybe when he decides to
develop a macro package for Amanda he will appreciate the beauty of
Lisp syntax.
Regarding the differences between quoting of functions and constants
and the differences between funcall and apply maybe he can take a look
at Scheme (another member of the Lisp family) where those differences
are somewhat reduced (at the expense of other problems, of course).
Ant�nio Leit�o.
Michiel Borkent wrote:
> Hello folks,
>
> I am asking for some help with Lisp propaganda.
>
> Why should a programmer choose for Lisp, while there are also very
> much other functional languages, like Clean, Haskell, of which the
> syntax is very much more elegant (according to their users).
>
> So: why Lisp and not another functional language?
>
> I am asking this because I am in kind of a discussion about Lisp, what
> it can do and express, with a teacher who uses preferably other
> functional languages.
> His most important critic on Lisp is...
Since he already knows Lisp, no propaganda will help. He has made his
choice already. Even if there were an objective proof that Lisp was
better, it would only piss him off; academics do not like being shown
up. Nor do academics write much code, which is why they can choose
languages based on silly things like brevity of code or brevity of the
spec for the language, as with scheme.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
> better, it would only piss him off; academics do not like being shown
> up.
yeah, they're just like normal people in that respect...
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
Joost Kremers <············@yahoo.com> writes:
> Kenny Tilton wrote:
>> better, it would only piss him off; academics do not like being shown
>> up.
>
> yeah, they're just like normal people in that respect...
>
I have found them, generally, to be quite a bit worse. For example
show your average plumber a better way then he currently uses to run
pipe he/she will generally be happy that you just made his job easier
and the equivalent is just not generally true with college professors.
This is based on what I have observed when in college.
marc
Marc Spitzer wrote:
> Joost Kremers <············@yahoo.com> writes:
>
>
>>Kenny Tilton wrote:
>>
>>>better, it would only piss him off; academics do not like being shown
>>>up.
>>
>>yeah, they're just like normal people in that respect...
>>
>
>
> I have found them, generally, to be quite a bit worse. For example
> show your average plumber a better way then he currently uses to run
> pipe he/she will generally be happy that you just made his job easier
> and the equivalent is just not generally true with college professors.
>
> This is based on what I have observed when in college.
>
> marc
When did you study with plumbers?
Seriously though, I have the same _impression_ as you, but it's just my
opinion. I don't have much factual data to back it up.
David Sletten
Joost Kremers wrote:
> Kenny Tilton wrote:
>
>>better, it would only piss him off; academics do not like being shown
>>up.
>
>
> yeah, they're just like normal people in that respect...
>
nah, profs depend more than normal people for their social status on
being experts in their field, and they are commensurately more sensitive
to being shown up. For this reason one can look with compassion on their
pigheadedness. Compassion and -- back on topic -- caution if one is a
second-class citizen, aka student. :)
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <····························@posting.google.com>,
··············@gmail.com (Michiel Borkent) wrote:
> Hello folks,
>
> I am asking for some help with Lisp propaganda.
>
> Why should a programmer choose for Lisp, while there are also very
> much other functional languages, like Clean, Haskell, of which the
> syntax is very much more elegant (according to their users).
>
> So: why Lisp and not another functional language?
>
> I am asking this because I am in kind of a discussion about Lisp, what
> it can do and express, with a teacher who uses preferably other
> functional languages.
> His most important critic on Lisp is that the syntax is so ugly
> compared to the syntax of his language of choice (Amanda). The
> uglyness of the Lisp syntax lies in the different quoting of functions
> and constants and the strange ways of applying functions with funcall
> and apply, while in his language these ugly syntactical constructs are
> not necessary to do what is necessary.
>
> Example:
>
> Lisp:
>
> (defun twice (fun)
> (lambda (&rest args)
> (apply fun
> (apply fun args)
> )))
>
> Amanda:
>
> double f = args -> f (f args)
>
> Lisp:
>
> (funcall (twice #'(lambda(x y) (list (* x y)(+ x y)))) 1 3)
>
> Amanda:
>
> double ((x,y) -> (x*y,x+y)) (1,3)
>
> Please help me out :).
>
> Michiel
The Amanda code uses a tuple as a single argument. Your
Lisp code does something different.
So I think there are a few minor problems with the Lisp code
above. I would not use APPLY twice. Only once. See below.
You don't want to APPLY the results of the first function
call.
(defun twice (fun)
(lambda (&rest args)
(funcall fun
(apply fun args))))
(funcall (twice #'(lambda (tuple)
(destructuring-bind (x y)
tuple
(list (* x y) (+ x y)))))
(list 1 3))
Well, you can always find toy problems where
one language is better than others. Does Amanda
have named arguments similar to Common Lisp?
Does Amanda scale to large software? Does it support
object-oriented programming? Can you change
it's syntax? Can you program the language itself?
Amanda is a academic toy language (a free language
similar to the commercial Miranda). Common Lisp
is a language for writing applications from small
to large scale. They serve entirely different purposes.
Lisp syntax maybe ugly to some, but it is extremely
practical. Various pieces of advocacy on the the net
are describing why the syntax is like it is, why
people tried to invent better syntaxes for Lisp and
why they failed. ;-)
Besides of that there do exist some nice functional
languages that don't look too much like Lisp:
OCAML and Haskell. You can get productivity out of these,
but if you really want you can change Lisp so that
it stays ahead. See for example this old paper:
http://www.cs.pdx.edu/~apt/cs457_2003/hudak-jones.pdf
See that the Lisp version in above study just took
three hours to develop and compare that to the competitors. ;-)
If you enhance your Lisp with some domain-specific
tools (-> Lisp as programmable programming language) you
get the demonstrated improvement in productivity.
··············@gmail.com (Michiel Borkent) writes:
> I am asking this because I am in kind of a discussion about Lisp, what
> it can do and express, with a teacher who uses preferably other
> functional languages.
> His most important critic on Lisp is that the syntax is so ugly
> compared to the syntax of his language of choice (Amanda). The
> uglyness of the Lisp syntax lies in the different quoting of functions
> and constants and the strange ways of applying functions with funcall
> and apply, while in his language these ugly syntactical constructs are
> not necessary to do what is necessary.
Well, be sure to call his language a pile of crap :-)
Seriously, though, I would rather go the route of informed
dissent. Say that your opinion is different and that you would like to
use lisp.
Convincing him of letting you use lisp has a far higher chance of
succeeding than convincing him that lisp is better than Amanda,
because that is the way he wants things to be. In my experience,
people who manage to hate things like funcall aren't really accessible
for arguments.
From: Rahul Jain
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <87hdpkx0cb.fsf@nyct.net>
Mario S. Mommer <········@yahoo.com> writes:
> In my experience, people who manage to hate things like funcall aren't
> really accessible for arguments.
They're inaccessible for both arguments AND the operator being
determined at run-time, actually...
;)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Jeff
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <tzf5d.259091$Fg5.2103@attbi_s53>
Michiel Borkent wrote:
> Why should a programmer choose for Lisp, while there are also very
> much other functional languages, like Clean, Haskell, of which the
> syntax is very much more elegant (according to their users).
>
> So: why Lisp and not another functional language?
I'm sure you will get many good answers to this question from very
well-respected Lisp users. I'm still learning Lisp, but I thought I'd
take a stab at this (since I've used Clean/Haskell) without "looking at
the other answers" ;)
Lisp is not *purely* functional. It can be used that way, but Lisp can
be used imperatively, too. It is good to note that almost nothing "real
world" can be done with a purely functional language (without the use
of monads). There's networking, I/O, etc. to consider.
Lisp's syntax is its advantage over Haskell and other similar
languages. The Haskell family of languages are very good languages,
given the problem you want to solve. However, in Haskell it is
impossible to write code that writes code. The fact is there is nothing
Haskell can do that Lisp can't (while there is plenty that Lisp can do
that Haskell can't). How do you make a macro in Haskell? However, in
fairness, what Haskell does, it does with brevity.
Lisp can (against popular propoganda) create some very fast code. Many
times, this is accomplished by doing operations in-place as opposed to
creating more short-lived objects on the heap to be collected later.
The most common source code example for Haskell is quicksort:
qsort [] = []
qsort (x:xs) = qsort smaller ++ [x] ++ qsort larger
where
smaller = [y | y <- xs, y < x],
larger = [y | y <- xs, y >= x]
Very brief, to the point and easy to read (if you understand the list
generation syntax). However, let's examine it against the Lisp version.
The Lisp version is equally simple:
(defun qsort (list)
(if (null list)
nil
(let* ((x (car list))
(xs (cdr list))
(smaller (loop for y in xs when (< y x) collect y))
(larger (loop for y in xs when (>= y x) collect y)))
(append (qsort smaller) (list x) (qsort larger)))))
These two functions now have functionally equivelant syntax. The
Haskell version just hides the IF and the CAR/CDR. But I would actually
argue that the LOOPs in Lisp are more readable than the list generators
in Haskell. However, both of these suffer from being very slow. In
Lisp, we could rewrite this function to swap elements in-place (which
is what SORT does). How would you recode the Haskell version to sort
in-place?
These problems are small in scope, though. If you tried to write a
significantly large enough program with either of these languages, I
think you would come to the same conclusion (assuming you were equally
proficient in each language).
Jeff
--
Progress in computer technology is waiting for people to stop
re-inventing the wheel.
- Dr. William Bland (comp.lang.lisp)
Jeff wrote:
>> So: why Lisp and not another functional language?
> Lisp is not *purely* functional. It can be used that way, but Lisp can
> be used imperatively, too. It is good to note that almost nothing "real
> world" can be done with a purely functional language (without the use
> of monads). There's networking, I/O, etc. to consider.
Then use monads (or uniqueness-typing, or ...).
> Lisp's syntax is its advantage over Haskell and other similar
> languages. The Haskell family of languages are very good languages,
> given the problem you want to solve. However, in Haskell it is
> impossible to write code that writes code. The fact is there is nothing
> Haskell can do that Lisp can't (while there is plenty that Lisp can do
> that Haskell can't). How do you make a macro in Haskell?
You use Template Haskell?
> These two functions now have functionally equivelant syntax. The
> Haskell version just hides the IF and the CAR/CDR. But I would actually
> argue that the LOOPs in Lisp are more readable than the list generators
> in Haskell. However, both of these suffer from being very slow. In
> Lisp, we could rewrite this function to swap elements in-place (which
> is what SORT does). How would you recode the Haskell version to sort
> in-place?
By using monads that support mutable arrays?
Best regards,
Tom
--
.signature: Too many levels of symbolic links
Tomasz Zielonka wrote:
> Jeff wrote:
> >> So: why Lisp and not another functional language?
>
> > It is good to note that almost nothing
> > "real world" can be done with a purely functional language (without
> > the use of monads). ^^^^^^^
^^^^^^^^^^^^^^^^^
> Then use monads (or uniqueness-typing, or ...).
Did you miss this?
>
> > How do you make a macro in Haskell?
>
> You use Template Haskell?
>
> > In Lisp, we could rewrite this function to swap
> > elements in-place (which is what SORT does). How would you recode
> > the Haskell version to sort in-place?
>
> By using monads that support mutable arrays?
Suddenly elegance is out the window ;)
Jeff
--
Progress in computer technology is waiting for people to stop
re-inventing the wheel.
- Dr. William Bland (comp.lang.lisp)
Jeff wrote:
> Tomasz Zielonka wrote:
>
>> Jeff wrote:
>> >> So: why Lisp and not another functional language?
>>
>> > It is good to note that almost nothing
>> > "real world" can be done with a purely functional language (without
>> > the use of monads). ^^^^^^^
> ^^^^^^^^^^^^^^^^^
>
>> Then use monads (or uniqueness-typing, or ...).
>
> Did you miss this?
No, but I should write ,,Then use them'' to make this clear.
>> By using monads that support mutable arrays?
>
> Suddenly elegance is out the window ;)
Unfortunately, there is some trade off between efficiency and elegance.
But it's good to have the choice, otherwise Haskell would be an academic
toy forever.
BTW, using the ST monad you can implement sorting imperatively, but
still give it a pure function interface.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
From: Mikael Brockman
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <87isa2cpoc.fsf@igloo.phubuh.org>
"Jeff" <···@nospam.insightbb.com> writes:
> Tomasz Zielonka wrote:
>
> > Jeff wrote:
> > >> So: why Lisp and not another functional language?
> >
> > > It is good to note that almost nothing
> > > "real world" can be done with a purely functional language (without
> > > the use of monads). ^^^^^^^
> ^^^^^^^^^^^^^^^^^
>
> > Then use monads (or uniqueness-typing, or ...).
>
> Did you miss this?
It's like you're saying ``Lisp can't be used for I/O (without the use of
functions that do I/O).''
From: Jeff
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <sdi5d.156526$3l3.70293@attbi_s03>
Mikael Brockman wrote:
> "Jeff" <···@nospam.insightbb.com> writes:
>
> It's like you're saying ``Lisp can't be used for I/O (without the use
> of functions that do I/O).''
I can see how my comments could be seen in that light.
Perhaps because I don't understand monads completely, but I consider
them just an aweful hack to get something to work that otherwise
wouldn't. I'll be the first to admit, though, that I'm probably just
flaunting my ignorance ;)
I'm coming from a very embedded programming background. I have yet to
see a purely functional language come up with a very simple construct
to set a various piece of memory on a device, because they don't handle
state changes well. Consider the following in C:
#define REG_DISPLAY_CONTROL (*((unsigned char*)0x4000000))
void main() {
REG_DISPLAY_CONTROL = 3;
}
IMO, this is a very real situation. I need to set a hardware virtual
register to some value. There is no way (that I'm aware of) to easily
do this using the functional paradigm. Lisp is wonderful because it
gives me equal access to both the functional and imperative paradigms.
It allows me to choose which one is best suited for the problem at hand.
Jeff
--
Progress in computer technology is waiting for people to stop
re-inventing the wheel.
- Dr. William Bland (comp.lang.lisp)
From: Paul F. Dietz
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <OeCdne1VF90RXsjcRVn-sQ@dls.net>
Jeff wrote:
> Perhaps because I don't understand monads completely, but I consider
> them just an aweful hack to get something to work that otherwise
> wouldn't. I'll be the first to admit, though, that I'm probably just
> flaunting my ignorance ;)
Frankly, if a language requires the use of third-order functions
to do something basic, I consider there to be something wrong with
the concept behind the language.
Space leakage due to lazy evaluation is another problem.
Paul
Paul F. Dietz wrote:
> Frankly, if a language requires the use of third-order functions
> to do something basic, I consider there to be something wrong with
> the concept behind the language.
Even if we assume that IO action is represented as a world-passing
function, it's only second-order ;)
But of course you still have a point here.
My reply is that monads are amazingly flexible and easy to use when you
get them. Getting them can be hard, but it pays off IMO.
> Space leakage due to lazy evaluation is another problem.
Indeed.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
From: Oliver Korpilla
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <cjb888$dj1$1@wsc10.lrz-muenchen.de>
Tomasz Zielonka wrote:
> Paul F. Dietz wrote:
>
>>Frankly, if a language requires the use of third-order functions
>>to do something basic, I consider there to be something wrong with
>>the concept behind the language.
>
>
> Even if we assume that IO action is represented as a world-passing
> function, it's only second-order ;)
> But of course you still have a point here.
>
> My reply is that monads are amazingly flexible and easy to use when you
> get them. Getting them can be hard, but it pays off IMO.
I peeked at several sources yesterday, and at my copy of "Haskell - The Craft of
Functional Programming", and they are understandable, but not necessarily
intuitive or easy to design.
This is true for most stuff in Haskell: If you carefully craft a piece of math,
prove it, find a way to execute it efficiently, it usually translates directly
to Haskell. It's elegant. It's the language of the well-thought-out solution.
That's why it is and will be a language for academe: It makes trivial computer
problems hard (I/O is the 1st thing you do in any other language, and one of the
last in a Haskell book - page 386 in my copy for "Hello, World!"), and hard
stuff straight to write.
It's considerably "anti-hacking", but of course that's only my little-informed
opinion. It's close to being a domain language (for math and complex data
structures) with features on top of it to make it a general-purpose language again.
For me, Haskell is like C++, in that I consider it again and again, learn
something from it (or not) and then leave for greener pastures, like Common
Lisp, where common problems are vastly more easily and efficiently solved. Both
languages limit you in a way - and surely to a great deal to their strong
typing. Typing is a tool, not something that someone should cram into you. It
may only be my impression, but CL limits you least in your ability to express
something as a program, in a way natural to the implementer. Make it functional,
where possible, make it imperative, where needed, make it object-oriented, where
state plays a major role. Mix and enjoy.
While monads are of great beauty, I find them a very complex concept simply to
say: I need an ordered execution of instructions. Because that's what the box
they're executing on is built for.
Ah, just my exaggerated 2 cents.
Regards,
Oliver
Oliver Korpilla wrote:
> That's why it is and will be a language for academe:
BTW, I am hardly an academic - just an ex-student working as a regular
(mostly C++) software engineer for about 4 years.
> It makes trivial computer problems hard (I/O is the 1st thing you do
> in any other language, and one of the last in a Haskell book - page
> 386 in my copy for "Hello, World!"), and hard stuff straight to write.
Hmmm, when I have to solve some difficult problem involving networking,
IO, concurrency, etc. often the first tool I reach for is GHC - a
Haskell compiler.
I see it this way:
IO in Haskell *is* difficult to get at first
Later it is easier and easier to use
At some point you can notice, that it has become easier
for you to do IO in Haskell than in traditionally
imperative languages
It will differ from problem to problem.
Sometimes it can be a problem to get the desired efficiency.
But it's easier to get the semantics right, and I prefer to
start from the right semantics and then work on efficiency,
rather than going in opposite direction.
But, YMMV.
> Typing is a tool, not something that someone should cram into you. It
> may only be my impression, but CL limits you least in your ability to
> express something as a program, in a way natural to the implementer.
Unless the implementer finds it natural to design in types.
I will also point out that unlike many other statically typed
languages, which force you to clutter code with type declarations,
Haskell's typing can actually make programs shorter, because of
type-classes.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
From: kodifik
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <opse4q9qv3gnmoe1@ex.egaran>
There are "practical" reasons to prefer lisp against other functional
prog. lang.
(number of speakers, both human and machines, SPEED, etc.) and there are
intrinsic
reasons: 1- programs and data are represented by the same basic
construction 2- It is
a functional lang. only if you want it to be functional, but it can be an
obj. oriented lang.
if you want it to be that, or whatever other style (aspect oriented,
applicative,
descriptive, mathematical, fashioned...) so you are not forced to switch
to another
tongue to talk about different things.
Jeff wrote:
> Perhaps because I don't understand monads completely, but I consider
> them just an aweful hack to get something to work that otherwise
> wouldn't. I'll be the first to admit, though, that I'm probably just
> flaunting my ignorance ;)
Monads have many other uses beside enabling imperative programming in
a pure FPL. I don't consider it a hack. I often use them even if I need
any imperative stuff, eg. for parsing and unparsing.
> I'm coming from a very embedded programming background. I have yet to
> see a purely functional language come up with a very simple construct
> to set a various piece of memory on a device, because they don't handle
> state changes well. Consider the following in C:
>
> #define REG_DISPLAY_CONTROL (*((unsigned char*)0x4000000))
>
> void main() {
> REG_DISPLAY_CONTROL = 3;
> }
You can do this using foreign function interface.
> IMO, this is a very real situation. I need to set a hardware virtual
> register to some value. There is no way (that I'm aware of) to easily
> do this using the functional paradigm. Lisp is wonderful because it
> gives me equal access to both the functional and imperative paradigms.
And so does Haskell.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
Stefan Ram wrote:
This is the best tutorial on monads in this regard I am aware
of - I believe I will need to read it slowly just two or three
more times to comprehend the notion:
Message-ID: <····················@gs3106.sp.cs.cmu.edu>
http://groups.google.com/groups?selm=slrnc3781u.oor.neelk%40gs3106.sp.cs.cmu.edu
I've had a look
o Q: What is a monad?
A: Monads are a concept from category theory, which functional
programmers have adapted to create a useful design pattern for
combinator libraries.
So I'm expecting a collection of objects, and for any two
objects a set of morphisms. If "f" is a morphism from object
`a' to object `b' and "g" is a morphism from object `b' to
object `c', then I can compose "f" and "g" to get "h", a
morphism from `a' to `c'.
For example, let the morphisms be lengths of steel rod, with
a female thread on one end, and a male thread on the other
end. Let the objects be threads, eg 4 BA, 5/16 inch
Whitworth, 6mm ISO metric.
If the rod marked "f" has a 4BA thread on one end and a 5/16 Whitworth
socket on the other, and the rod marked "g" has a 5/16
Whitworth thread on one end and a 6mm ISO metric socket on
the other, we screw the Whitworth ends together, to get a
rod that is BA at one end and metric at the other.
Categories are very concrete things that one can machine on
a lathe out of round bar. If you want to explain something
and can say "Its a category, these are the objects, those
are the morphisms." your listener quickly gains an image of
how it fits together.
The article starts out OK with
2. A function 'unit', which has type 'a -> M[a]'.
That is, it takes a value of type a, and injects it
into the monadic type.
One of the axioms of category theory is that the set of
morphisms from an object to itself always has at least one
element, the null coupler, with the same thread on each end
(male on one, female on the other). So it is starting to
shape up, with an object -a- and a morphism -M[a]-
Then the article goes off in a different direction
3. A function 'bind', of type '(M[a], a -> M[b]) -> M[b]'.
bind is a function taking two arguments -- the first is a
monadic value of type M[a], and the second is a function that,
given an a, returns a monadic value of type M[b]. It then
returns a value of type M[b].
There is no sign of M[a,b], a morphism from a to b.
Anyone want to jump in a say what the objects are and what
the morphisms are?
Alan Crowe
The Mathematical Machine Shop
Edinburgh
Scotland
Alan Crowe wrote:
> The article starts out OK with
>
> 2. A function 'unit', which has type 'a -> M[a]'.
> That is, it takes a value of type a, and injects it
> into the monadic type.
>
> One of the axioms of category theory is that the set of
> morphisms from an object to itself always has at least one
> element, the null coupler, with the same thread on each end
> (male on one, female on the other). So it is starting to
> shape up, with an object -a- and a morphism -M[a]-
>
> Then the article goes off in a different direction
>
> 3. A function 'bind', of type '(M[a], a -> M[b]) -> M[b]'.
> bind is a function taking two arguments -- the first is a
> monadic value of type M[a], and the second is a function that,
> given an a, returns a monadic value of type M[b]. It then
> returns a value of type M[b].
>
> There is no sign of M[a,b], a morphism from a to b.
>
> Anyone want to jump in and say what the objects are and what
> the morphisms are?
The objects are types. The morphisms are functions.
A monad (in the functional programming sense) is more
or less a functor M from Types to Types, plus a natural
transformation "unit" from the identity functor on Types to M.
I say "more or less" because an extra constraint gets
imposed in FP-land. Since M is a functor, we know that
for any types x,y and any function f:x->y there must be
a function Mf:Mx->My. Well, what an FP-monad requires
is that given any g:x->My there must be bind(g):Mx->My,
so that when f:x->y, bind(unit*f) will serve as Mf.
The three "algebraic laws" stated (misleadingly, since
"M" in them is just a free variable and nothing to do
with the monad M) in the article imply respectively
that "unit" is a natural transformation, that M behaves
functorially on identity functions, and that M behaves
functorially on compositions.
In category theory, a monad for a category X is a
functor M from X to X, plus a natural transformation
from the identity functor on X to M, *plus* another
natural transformation from M*M to M, such that
certain conditions hold.
So it looks as if an FP-monad is both less than a CT-monad
(because it doesn't need the second natural transformation
and the associated constraints) and more than a CT-monad
(because of the special form Mf always has). Perhaps the
two apparent discrepancies cancel out in some subtle way,
but I don't know enough either about category theory or
about functional programming to see how.
--
Gareth McCaughan
.sig under construc
From: Neelakantan Krishnaswami
Subject: Re: Monads -- was Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <slrnclkcgf.u2c.neelk@gs3106.sp.cs.cmu.edu>
In article <·················@g.mccaughan.ntlworld.com>, Gareth McCaughan
wrote:
>
> In category theory, a monad for a category X is a functor M from X
> to X, plus a natural transformation from the identity functor on X
> to M, *plus* another natural transformation from M*M to M, such that
> certain conditions hold.
>
> So it looks as if an FP-monad is both less than a CT-monad (because
> it doesn't need the second natural transformation and the associated
> constraints) and more than a CT-monad (because of the special form
> Mf always has). Perhaps the two apparent discrepancies cancel out in
> some subtle way, but I don't know enough either about category
> theory or about functional programming to see how.
Technically, a Haskell-style monad is a Kleisli triple, which is a
construction equivalent to a CT monad, but with slightly different
operations. (That is, you can build the monadic natural transforms out
of bind and unit, and vice versa.) The operations in a Kleisli triple
are more pleasant for real programming than the "real" monadic ones
do, which is why Haskell chose that route.
--
Neel Krishnaswami
·····@cs.cmu.edu
From: Alan Crowe
Subject: Re: Monads -- was Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <86655xl3ga.fsf@cawtech.freeserve.co.uk>
Gareth McCaughan explained:
> The objects are types. The morphisms are functions. A
> monad (in the functional programming sense) is more or
> less a functor M from Types to Types, plus a natural
> transformation "unit" from the identity functor on Types
> to M. I say "more or less" because an extra constraint
> gets imposed in FP-land. Since M is a functor, we know
> that for any types x,y and any function f:x->y there must
> be a function Mf:Mx->My. Well, what an FP-monad requires
> is that given any g:x->My there must be bind(g):Mx->My, so
> that when f:x->y, bind(unit*f) will serve as Mf. The
> three "algebraic laws" stated (misleadingly, since "M" in
> them is just a free variable and nothing to do with the
> monad M) in the article imply respectively that "unit" is
> a natural transformation, that M behaves functorially on
> identity functions, and that M behaves functorially on
> compositions.
Thank you. I was trying to interpret the three "algebraic
laws" stated in the article as relating to the axioms for
the category, and getting nowhere. Now I know that they
relate to the axioms for a functor, it makes more sense.
Now I can re-read the article and try to work out the
connection to simulating side effects in a functional
language.
Alan Crowe
Edinburgh
Scotland
From: Neelakantan Krishnaswami
Subject: Re: Monads -- was Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <slrncllmtt.3qf.neelk@gs3106.sp.cs.cmu.edu>
In article <··············@cawtech.freeserve.co.uk>, Alan Crowe wrote:
>
> Thank you. I was trying to interpret the three "algebraic laws"
> stated in the article as relating to the axioms for the category,
> and getting nowhere. Now I know that they relate to the axioms for a
> functor, it makes more sense.
Sorry about any confusion!
I was trying to downplay the connection to category theory as much as
possible in that post, because for some reason most people are less
intimidated when told they can think of a monad as a "design pattern"
rather than "a composition of adjoint functors". :)
But if you find category theory a natural presentation, then my little
Usenet post is likely to cause you substantial confusion, and I urge
you to read Eugenio Moggi's papers "Computational Lambda Calculus and
Monads" and "Notions of Computations and Monads" which is much more
careful, precise and explicit about the connection.
<http://www.disi.unige.it/person/MoggiE/ftp/lics89.pdf>
<http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf>
--
Neel Krishnaswami
·····@cs.cmu.edu
In article <·····················@attbi_s53>,
"Jeff" <···@nospam.insightbb.com> wrote:
> Michiel Borkent wrote:
>
> > Why should a programmer choose for Lisp, while there are also very
> > much other functional languages, like Clean, Haskell, of which the
> > syntax is very much more elegant (according to their users).
> >
> > So: why Lisp and not another functional language?
>
> I'm sure you will get many good answers to this question from very
> well-respected Lisp users. I'm still learning Lisp, but I thought I'd
> take a stab at this (since I've used Clean/Haskell) without "looking at
> the other answers" ;)
>
> Lisp is not *purely* functional. It can be used that way, but Lisp can
> be used imperatively, too. It is good to note that almost nothing "real
> world" can be done with a purely functional language (without the use
> of monads). There's networking, I/O, etc. to consider.
>
> Lisp's syntax is its advantage over Haskell and other similar
> languages. The Haskell family of languages are very good languages,
> given the problem you want to solve. However, in Haskell it is
> impossible to write code that writes code. The fact is there is nothing
> Haskell can do that Lisp can't (while there is plenty that Lisp can do
> that Haskell can't). How do you make a macro in Haskell? However, in
> fairness, what Haskell does, it does with brevity.
>
> Lisp can (against popular propoganda) create some very fast code. Many
> times, this is accomplished by doing operations in-place as opposed to
> creating more short-lived objects on the heap to be collected later.
> The most common source code example for Haskell is quicksort:
>
> qsort [] = []
> qsort (x:xs) = qsort smaller ++ [x] ++ qsort larger
> where
> smaller = [y | y <- xs, y < x],
> larger = [y | y <- xs, y >= x]
>
> Very brief, to the point and easy to read (if you understand the list
> generation syntax). However, let's examine it against the Lisp version.
> The Lisp version is equally simple:
>
> (defun qsort (list)
> (if (null list)
> nil
> (let* ((x (car list))
> (xs (cdr list))
> (smaller (loop for y in xs when (< y x) collect y))
> (larger (loop for y in xs when (>= y x) collect y)))
> (append (qsort smaller) (list x) (qsort larger)))))
or with some syntactic sugar (list comprensions and
the select-match macro from Stephen Adams (1990 ;-) )
it looks like this (in Common Lisp!):
(amanda qs (l)
() => '()
(pivot . x) => (append (qs [y (y <- x) (< y pivot)])
(list pivot)
(qs [y (y <- x) (>= y pivot)])))
··············@gmail.com (Michiel Borkent) writes:
> Hello folks,
>
> I am asking for some help with Lisp propaganda.
>
> Why should a programmer choose for Lisp, while there are also very
> much other functional languages, like Clean, Haskell, of which the
> syntax is very much more elegant (according to their users).
>
> So: why Lisp and not another functional language?
>
> I am asking this because I am in kind of a discussion about Lisp, what
> it can do and express, with a teacher who uses preferably other
> functional languages.
> His most important critic on Lisp is that the syntax is so ugly
> compared to the syntax of his language of choice (Amanda). The
> uglyness of the Lisp syntax lies in the different quoting of functions
> and constants and the strange ways of applying functions with funcall
> and apply, while in his language these ugly syntactical constructs are
> not necessary to do what is necessary.
>
> Example:
>
> Lisp:
>
> (defun twice (fun)
> (lambda (&rest args)
> (apply fun
> (apply fun args)
> )))
>
> Amanda:
>
> double f = args -> f (f args)
(defunal double f (-> args (f (f args))))
> Lisp:
>
> (funcall (twice #'(lambda(x y) (list (* x y)(+ x y)))) 1 3)
>
> Amanda:
>
> double ((x,y) -> (x*y,x+y)) (1,3)
((double (-> (x y) ((* x y) (+ x y)))) (1 3))
> Please help me out :).
1- Search google news in c.l.l for the macro that will allow to written
Lisp-1 code in Common-Lisp (or try scheme), and use it to define a
"lisp-1" macro:
;; From: Pascal Costanza <········@web.de>
;; Subject: Scheme-like expressions in CL
;; Newsgroups: comp.lang.lisp
;; Date: Fri, 06 Jun 2003 23:50:30 +0200
2- define some macros:
(defmacro -> (argument body)
(let ((arg (gensym "arg")))
`(lambda (,arg)
(destructuring-bind ,(if (consp argument) argument (list argument))
,arg `(lisp-1 ,body)))))
(defmacro defunal (name argument body)
(let ((arg (gensym "arg")))
`(defun ,name (,arg)
(destructuring-bind
,(if (consp argument) argument (list argument))
,arg `(lisp-1 ,body)))))
(defmacro funal (body) `(lisp-1 ,body))
(defunal double f (-> args (f (f args))))
(funal ((double (-> (x y) ((* x y) (+ x y)))) (1 3)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
In article <··············@thalassa.informatimago.com>, Pascal
Bourguignon wrote:
> ··············@gmail.com (Michiel Borkent) writes:
>> I am asking for some help with Lisp propaganda.
[snip]
>> Example:
>>
>> Lisp:
>>
>> (defun twice (fun)
>> (lambda (&rest args)
>> (apply fun
>> (apply fun args)
>> )))
>>
>> Amanda:
>>
>> double f = args -> f (f args)
>
> (defunal double f (-> args (f (f args))))
>
>> Lisp:
>>
>> (funcall (twice #'(lambda(x y) (list (* x y)(+ x y)))) 1 3)
>>
>> Amanda:
>>
>> double ((x,y) -> (x*y,x+y)) (1,3)
>
> ((double (-> (x y) ((* x y) (+ x y)))) (1 3))
>
>> Please help me out :).
>
> 1- Search google news in c.l.l for the macro that will allow to written
> Lisp-1 code in Common-Lisp (or try scheme), and use it to define a
> "lisp-1" macro:
>
> ;; From: Pascal Costanza <········@web.de>
> ;; Subject: Scheme-like expressions in CL
> ;; Newsgroups: comp.lang.lisp
> ;; Date: Fri, 06 Jun 2003 23:50:30 +0200
>
> 2- define some macros:
[snip macros]
And then, when/if he says "but I have that syntax built in; you have
to define it", whip out some other macros that define some other
syntax. Something *not* in his favorite language. See how long it
takes *him* to emulate *that* syntax. See how much it looks like
normal Amanda. :)
Actually, though, I think your best bet is informed dissent, as stated
by a different poster. "You like Amanda; I like Lisp -- can we leave
it at that?"
--
Larry Clapp / ·····@theclapp.org
Use Lisp from Vim: VILisp: http://vim.sourceforge.net/script.php?script_id=221
Larry Clapp wrote:
> In article <··············@thalassa.informatimago.com>, Pascal
> Bourguignon wrote:
> > ··············@gmail.com (Michiel Borkent) writes:
> >> I am asking for some help with Lisp propaganda.
>
> > 1- Search google news in c.l.l for the macro that will allow to
written
> > Lisp-1 code in Common-Lisp (or try scheme), and use it to define
a
> > "lisp-1" macro:
> >
> > ;; From: Pascal Costanza <········@web.de>
> > ;; Subject: Scheme-like expressions in CL
> > ;; Newsgroups: comp.lang.lisp
> > ;; Date: Fri, 06 Jun 2003 23:50:30 +0200
> >
> > 2- define some macros:
> [snip macros]
>
> And then, when/if he says "but I have that syntax built in; you have
> to define it", whip out some other macros that define some other
> syntax. Something *not* in his favorite language. See how long it
> takes *him* to emulate *that* syntax. See how much it looks like
> normal Amanda. :)
By the same token, Michiel could also concede that Scheme's notation is
better than Lisp's conventional notation specifically for functional
programming. Some audiences appreciate a nuanced treatment. For
example, at yesterday's meeting, Jim Newton had a good treatment of
multiple inheritence in his proprietary CAD lisp dialect Skill. Where
he acknowledged the well-known arguments that MI could very well be
problematic in various situations, but empirically he found that MI has
been a natural way to express what one means.
Also Michiel could acknowledge that such examples for partitioning some
symbols into lisp1 notation are hard to find. Because it's a subject
which generates far more heat than light. Pascal Costanza's example is
not something a newbie would be expected to hack together, but rather
desire to search for.
From: Wade Humeniuk
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <zQi5d.51239$t61.20622@clgrps13>
Michiel Borkent wrote:
> Why should a programmer choose for Lisp, while there are also very
> much other functional languages, like Clean, Haskell, of which the
> syntax is very much more elegant (according to their users).
Not to be too repetitive (but I am trying to stay on message).
Because Lisp is cool. Clean, Haskell and Amanda are Girlie
Programmming Languages. :)
(Girlie: Throwing a ball like a girl.)
Wade
Am Sat, 25 Sep 2004 03:41:39 -0700 schrieb Michiel Borkent:
> Hello folks,
>
> I am asking for some help with Lisp propaganda.
>
> Why should a programmer choose for Lisp, while there are also very
> much other functional languages, like Clean, Haskell, of which the
> syntax is very much more elegant (according to their users).
>
> So: why Lisp and not another functional language?
>
Well, languages like lisp and Haskell represent two very different sides
of language design, even more so than lisp and c (imho). Haskell is
side-effect free, lisp not. Lisp is a very dynamic language, Haskell
static. Lisp has strict evaluation, Haskell lazy. And so on... These
differences are not disconnected. From the (im)pureness follow very
different concepts of object identity which results in lisp having a very
cool dynamic object system and haskell a very cool somewhat static pattern
matching system. AspectCL (and the authors paper) helped me to see what
aop is about (couldn't get that from the descriptions of what it does in
java) and how it comes into play in dynamic languages. The differences
also aren't insurmountable, 'they' use monads (and macros) to express more
imperative* things, we use closures, higher order functions (and macros)
to express more functional* things. So its all somehow moving together. At
least this is my view of the "Smalltalk, Lisp <---> Clean, Haskell" issue.
Unfortunately when different concepts of concurrency come into play it all
gets hazy for me :)
All that being said, I just happen to very strongly prefer the impure,
dynamic side. Perhaps because that's how the world is. Very impure and
dynamic ;)
.....
* please note that i'm not satisfied with these terms but i couldn't find
better ones.
From: Rahul Jain
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <87d608x01v.fsf@nyct.net>
Simon Adameit <·······@gmx.net> writes:
> 'they' use monads (and macros) to express more imperative* things
> * please note that i'm not satisfied with these terms but i couldn't find
> better ones.
Maybe "stateful" is a better word? Pure FP is basically stateless
programming.
Of course, Lisp has far more than simply imperative (stateful) and
functional programming. What about the libraries you can get to do logic
programming? How would you fit those in the haskell vs. lisp discussion?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Michiel Borkent wrote:
> Hello folks,
>
> I am asking for some help with Lisp propaganda.
>
> Why should a programmer choose for Lisp, while there are also very
> much other functional languages, like Clean, Haskell, of which the
> syntax is very much more elegant (according to their users).
>
> So: why Lisp and not another functional language?
>
> I am asking this because I am in kind of a discussion about Lisp, what
> it can do and express, with a teacher who uses preferably other
> functional languages.
Lisp is not a functional language, but a large bag of building material
with which you can create the language that is most appropriate for the
task at hand. If you need functional abstractions, you can use them. If
you need object-orieted abstractions, you can use them as well. And so on.
A language that accomodates a wide range of programming styles cannot be
"perfect" for one particular style out of the box.
> His most important critic on Lisp is that the syntax is so ugly
> compared to the syntax of his language of choice (Amanda). The
> uglyness of the Lisp syntax lies in the different quoting of functions
> and constants and the strange ways of applying functions with funcall
> and apply, while in his language these ugly syntactical constructs are
> not necessary to do what is necessary.
>
> Example:
>
> Lisp:
>
> (defun twice (fun)
> (lambda (&rest args)
> (apply fun
> (apply fun args)
> )))
>
> Amanda:
>
> double f = args -> f (f args)
>
> Lisp:
>
> (funcall (twice #'(lambda(x y) (list (* x y)(+ x y)))) 1 3)
>
> Amanda:
>
> double ((x,y) -> (x*y,x+y)) (1,3)
>
> Please help me out :).
This example is a toy example and doesn't prove anything. It's more
straightforward to express it in Scheme:
(define (twice fun)
(lambda args
(apply fun (apply fun args))))
((twice (lambda (x y) (list (* x y) (+ x y)))) 1 3)
There are ways to express this in more or less the same style in Common
Lisp, especially with Pseudoscheme -
http://www.swiss.ai.mit.edu/ftpdir/pseudo/
But that's besides the point.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Rahul Jain
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <87wtxxhnnh.fsf@nyct.net>
Pascal Costanza <········@web.de> writes:
>> Example:
>> Lisp:
>> (defun twice (fun)
>> (lambda (&rest args)
>> (apply fun
>> (apply fun args)
>> )))
>> Amanda:
>> double f = args -> f (f args)
I don't get this syntax. Why is f = args? args is passed to double, not
equal to its first arg...
>> Lisp:
>> (funcall (twice #'(lambda(x y) (list (* x y)(+ x y)))) 1 3)
>> Amanda:
>> double ((x,y) -> (x*y,x+y)) (1,3)
>> Please help me out :).
>
> This example is a toy example and doesn't prove anything. It's more
> straightforward to express it in Scheme:
>
> (define (twice fun)
> (lambda args
> (apply fun (apply fun args))))
>
> ((twice (lambda (x y) (list (* x y) (+ x y)))) 1 3)
(defun twice (fun &rest args)
(apply fun (apply fun args))))
(twice (lambda (x y) (list (* x y) (+ x y))) 1 3)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: M Jared Finder
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <2sujgvF1pa0okU1@uni-berlin.de>
Rahul Jain wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>>Example:
>>>Lisp:
>>>(defun twice (fun)
>>> (lambda (&rest args)
>>> (apply fun
>>> (apply fun args)
>>> )))
>>>Amanda:
>>>double f = args -> f (f args)
>
>
> I don't get this syntax. Why is f = args? args is passed to double, not
> equal to its first arg...
N.B. I have never seen or heard of Amanda before, I'm just trying to
make sense of example code.
It looks to me like the equals sign has the lowest priority in that line
of code. It is therefore saying that:
double f = args -> f ( f args )
double applied to f is defined as the function that maps 'args' to
f applied to f applied to args.
-- MJF
Rahul Jain wrote:
> (defun twice (fun &rest args)
> (apply fun (apply fun args))))
>
> (twice (lambda (x y) (list (* x y) (+ x y))) 1 3)
Sure, but the (toy!) example was about combining the function with
itself first and then applying it.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Vitaly Lugovsky
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <cjao37$4f8$1@inn.ihep.su>
Michiel Borkent <··············@gmail.com> wrote:
> I am asking for some help with Lisp propaganda.
>
> Why should a programmer choose for Lisp, while there are also very
> much other functional languages, like Clean, Haskell, of which the
> syntax is very much more elegant (according to their users).
>
> So: why Lisp and not another functional language?
One reason: defmacro.
Vitaly Lugovsky <···@dbcompas.ihep.su> wrote in message news:<············@inn.ihep.su>...
> Michiel Borkent <··············@gmail.com> wrote:
>
> > Why should a programmer choose for Lisp, while there are also very
> > much other functional languages, like Clean, Haskell, of which the
> > syntax is very much more elegant (according to their users).
> >
> > So: why Lisp and not another functional language?
>
> One reason: defmacro.
That is to simplify things too much. If I'm not entirely mistaken,
it's mostly the lack of lazy evaluation(combined with side-effect free
evaluation in some cases) that's the reason for a need of a macro
facility. For example, I think you can do a new "if" construct in
Haskell without macros.
Regards, Tommy
·········@yahoo.com (thallgren) wrote:
> That is to simplify things too much. If I'm not entirely mistaken,
> it's mostly the lack of lazy evaluation(combined with side-effect free
> evaluation in some cases) that's the reason for a need of a macro
> facility.
You are mostly, though not entirely, mistaken.
> For example, I think you can do a new "if" construct in
> Haskell without macros.
That, for example, is true. You could not, however, implement the
COND construct in Haskell without macros. Not that you'd want to,
of course, but the difference between IF and COND provides a nice
illustration of the larger technical point. For a more motivating
example, consider some application-specific variation of the CASE
construct.
Will
From: Marco Baringer
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <m2zn3aebo8.fsf@bese.it>
·········@yahoo.com (thallgren) writes:
> Vitaly Lugovsky <···@dbcompas.ihep.su> wrote in message news:<············@inn.ihep.su>...
>> Michiel Borkent <··············@gmail.com> wrote:
>>
>> > Why should a programmer choose for Lisp, while there are also very
>> > much other functional languages, like Clean, Haskell, of which the
>> > syntax is very much more elegant (according to their users).
>> >
>> > So: why Lisp and not another functional language?
>>
>> One reason: defmacro.
>
> That is to simplify things too much.
True, he didn't mention the MOP or read macros or restarts or
slime or string output streams or any of the other non-functional
goodies in common lisp.
> If I'm not entirely mistaken,
> it's mostly the lack of lazy evaluation(combined with side-effect free
> evaluation in some cases) that's the reason for a need of a macro
> facility. For example, I think you can do a new "if" construct in
> Haskell without macros.
so why does ghc have template haskell and rewrite rules? (this is a
sincere question).
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
From: marco
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <m2655ye3bm.fsf@bese.it>
"Marco Baringer" <··@bese.it> writes:
> True, he didn't mention the MOP or read macros or restarts or
> slime or string output streams or any of the other non-functional
> goodies in common lisp.
sorry, slime isn't (yet) part of the common lisp standard.
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
From: Vitaly Lugovsky
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <cjdl74$499$3@inn.ihep.su>
thallgren <·········@yahoo.com> wrote:
>> > Why should a programmer choose for Lisp, while there are also very
>> > much other functional languages, like Clean, Haskell, of which the
>> > syntax is very much more elegant (according to their users).
>> >
>> > So: why Lisp and not another functional language?
>>
>> One reason: defmacro.
>
> That is to simplify things too much. If I'm not entirely mistaken,
> it's mostly the lack of lazy evaluation(combined with side-effect free
> evaluation in some cases) that's the reason for a need of a macro
> facility. For example, I think you can do a new "if" construct in
> Haskell without macros.
But what if you need to build a new syntax? You may check out
what is possible with defmacro here: http://dslengine.sourceforge.net/
That is why there is a Template Haskell. And it could not be implemented
on top of the core Haskell.
--
V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl)
·········@yahoo.com (thallgren) wrote in message news:<····························@posting.google.com>...
> Vitaly Lugovsky <···@dbcompas.ihep.su> wrote in message news:<············@inn.ihep.su>...
> > Michiel Borkent <··············@gmail.com> wrote:
> >
> > > Why should a programmer choose for Lisp, while there are also very
> > > much other functional languages, like Clean, Haskell, of which the
> > > syntax is very much more elegant (according to their users).
> > >
> > > So: why Lisp and not another functional language?
> >
> > One reason: defmacro.
>
> That is to simplify things too much. If I'm not entirely mistaken,
> it's mostly the lack of lazy evaluation(combined with side-effect free
> evaluation in some cases) that's the reason for a need of a macro
> facility.
One assumption here is behind the word ``mostly'', the implication
being that the design of a programming language should be based on
statistics, such that features that don't reach some arbitrary quorum
among the programmer population are superfluous. By that assumption,
we should not have Lisp or Haskell at all, since they are ``mostly''
for intelligent programming which is rarely needed.
Another assumption here is that every expression specifies a value to
be computed, and the only question is when or whether to force that
value out. In fact, macros go way beyond that; they can assign
arbitrary meaning to an expression, quite possibly a meaning that has
nothing to do with producing a value!
Suppose you have
(a b (c d))
Here, (c d) does not necessarily mean call operator C with argument D.
For instance, if A is an alias for DEFCLASS, then B is a class name
symbol, and C D are the direct superclasses. No call to an operator or
function C takes place.
Real-world Lisp programs quite typically include lots of macros which
abstract in this way, and do not merely control the sequencing of
evaluation of ordinary expressions!
> For example, I think you can do a new "if" construct in
> Haskell without macros.
What implements the existing construct?
At some point, a Haskell implementation has to take Haskell source,
delimit it into tokens, arrange the tokens into abstract syntax trees
and perform some transformations.
I would say that internally, at least some of what is happening there
is a form of macro processing. For example a Haskell compiler might
take the syntax tree corresponding to some "do" syntax and expand it
into a tree that would be produced by the longer version.
The only question is whether, or how much of that processing you leave
open to the programmer: do you allow the programmer to hook his own
code into those processing stages, and how much of the language is
available there.
Lisp's openness means that you can, for instance, have a portable
implementation of a significant language feature like LOOP. You just
load it into your Lisp and there it is.
Here is a web page (right at haskell.org) where something called
``arrow syntax'' for Haskell is described. One of the two
implementations is a text-to-text filter! The second is hard-coded
into a compiler.
http://www.haskell.org/arrows/syntax.html
Bahahaha!
··············@gmail.com (Michiel Borkent) wrote in message news:<····························@posting.google.com>...
> Hello folks,
>
> I am asking for some help with Lisp propaganda.
>
> Why should a programmer choose for Lisp, while there are also very
> much other functional languages, like Clean, Haskell, of which the
> syntax is very much more elegant (according to their users).
>
> So: why Lisp and not another functional language?
>
> I am asking this because I am in kind of a discussion about Lisp, what
> it can do and express, with a teacher who uses preferably other
> functional languages.
Lisp is the first functional language I have used, however, I love the
fact that there are no strong typed types in Lisp (int double etc),
and that there is a GC. Also, Lisp operates on as few side effects as
possible. For example, I wrote a forward-chaining algorithm with no
side effects (it just returned lists as values), and showed it to my
math teacher who uses C++. Even she admited that my code looked
elegent. I think that is the most important thing about Lisp that you
will never really find implemented as beautifully in other languages.
The choice of being able to program without side effects.
> Example:
>
> Lisp:
>
> (defun twice (fun)
> (lambda (&rest args)
> (apply fun
> (apply fun args)
> )))
>
> Amanda:
>
> double f = args -> f (f args)
I've never heard of Amanda, it looks similar to Perl.... (lambda) also
looks a lot better than ->.
> Lisp:
>
> (funcall (twice #'(lambda(x y) (list (* x y)(+ x y)))) 1 3)
>
> Amanda:
>
> double ((x,y) -> (x*y,x+y)) (1,3)
>
> Please help me out :).
>
> Michiel
--
May the Source be with you.
Philip Haddad (neo88)
From: Matthew Danish
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <87sm8jzhgn.fsf@mapcar.org>
·············@gmail.com (Philip Haddad) writes:
> Lisp is the first functional language I have used, however, I love the
> fact that there are no strong typed types in Lisp (int double etc),
Sorry to disappoint you, then, because there is strong typing in Lisp,
and there is an integer type, along with a few floating-point types, a
rational type, a complex type, and many more.
> and that there is a GC. Also, Lisp operates on as few side effects as
> possible. For example, I wrote a forward-chaining algorithm with no
> side effects (it just returned lists as values), and showed it to my
> math teacher who uses C++. Even she admited that my code looked
> elegent. I think that is the most important thing about Lisp that you
> will never really find implemented as beautifully in other languages.
> The choice of being able to program without side effects.
Sounds pretty inefficient though. The real beauty is that you can
write code like this, and yet also implement it efficiently;
oftentimes while hiding the cruft.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
·············@gmail.com (Philip Haddad) writes:
> I know that. What I said didn't come out right. I meant to say that
> Lisp will automatically allocate space (in the form of cons cells) for
> any new data object. You don't HAVE to actually type in the type if
> you don't want to.
You mean "dynamic typing" as opposed to "static typing".
--jon
Jon Boone <········@delamancha.org> wrote in message news:<··············@spiritus.delamancha.org>...
> ·············@gmail.com (Philip Haddad) writes:
>
> > I know that. What I said didn't come out right. I meant to say that
> > Lisp will automatically allocate space (in the form of cons cells) for
> > any new data object. You don't HAVE to actually type in the type if
> > you don't want to.
>
> You mean "dynamic typing" as opposed to "static typing".
Yeah those are the correct terms I suppose ;-)
> --jon
--
May the Source be with you.
Philip Haddad
Kenny Tilton <·······@nyc.rr.com> writes:
> [...]
> c.l.l is, as Rodney would have said, a tough
> crowd. you can count on anything less than rigorously perfect being
> hammered unmercilessly.
Hmmm, in the spirit of the pursuit of perfection, you can't actually
_count_ on that, but you ought to be prepared for it.
(Shamelessly paraphrasing and twisting words, "this is similar to
``should be hammered'' except that it does not imply that `extra
effort' has to be taken on the part of an poster to discover an
imperfect posting...")
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Duane Rettig wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Vassil Nikolov wrote:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>
>>>>[...]
>>>>c.l.l is, as Rodney would have said, a tough
>>>>crowd. you can count on anything less than rigorously perfect being
>>>>hammered unmercilessly.
>>>
>>> Hmmm, in the spirit of the pursuit of perfection, you can't
>>>actually
>>
>>> _count_ on that, but you ought to be prepared for it.
>>
>>Not bad, but I was hoping for "is there a merciful way to hammer someone?".
>
>
> Perhaps, but since "mercy" is not in the glossary, it would
> be an extension - implementation dependent.
>
Isn't anyone going to pick up on "unmercilessly"?
You guys are losing your edge.
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> Vassil Nikolov wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>[...]
> >>c.l.l is, as Rodney would have said, a tough
> >>crowd. you can count on anything less than rigorously perfect being
> >>hammered unmercilessly.
> > Hmmm, in the spirit of the pursuit of perfection, you can't
> > actually
> > _count_ on that, but you ought to be prepared for it.
>
> Not bad, but I was hoping for "is there a merciful way to hammer someone?".
Yes. Doctors do it sometimes when testing your reflexes.
--
Gareth McCaughan
.sig under construc
Duane Rettig <·····@franz.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> Vassil Nikolov wrote:
>> > Kenny Tilton <·······@nyc.rr.com> writes:
>> >
>>
>> >>[...]
>> >>c.l.l is, as Rodney would have said, a tough
>> >>crowd. you can count on anything less than rigorously perfect being
>> >>hammered unmercilessly.
>> > Hmmm, in the spirit of the pursuit of perfection, you can't
>> > actually
>>
>> > _count_ on that, but you ought to be prepared for it.
>>
>> Not bad, but I was hoping for "is there a merciful way to hammer someone?".
>
> Perhaps, but since "mercy" is not in the glossary, it would
> be an extension - implementation dependent.
... dropping gently
Upon the user beneath.
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Vassil Nikolov <········@poboxes.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >> Vassil Nikolov wrote:
> >> > Kenny Tilton <·······@nyc.rr.com> writes:
> >> >
> >>
> >> >>[...]
> >> >>c.l.l is, as Rodney would have said, a tough
> >> >>crowd. you can count on anything less than rigorously perfect being
> >> >>hammered unmercilessly.
> >> > Hmmm, in the spirit of the pursuit of perfection, you can't
> >> > actually
> >>
> >> > _count_ on that, but you ought to be prepared for it.
> >>
> >> Not bad, but I was hoping for "is there a merciful way to hammer someone?".
> >
> > Perhaps, but since "mercy" is not in the glossary, it would
> > be an extension - implementation dependent.
>
> ... dropping gently
> Upon the user beneath.
I think that interpretation of the Standard is a bit
strained. Isn't it a quality-of-implementation issue?
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Vassil Nikolov <········@poboxes.com> writes:
>
>> Duane Rettig <·····@franz.com> writes:
>> [...]
>> > Perhaps, but since "mercy" is not in the glossary, it would
>> > be an extension - implementation dependent.
>>
>> ... dropping gently
>> Upon the user beneath.
>
> I think that interpretation of the Standard is a bit
> strained. Isn't it a quality-of-implementation issue?
Perhaps; but then, some implementations are created with quality,
some achieve quality, and some have quality thrust upon them...
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
"List, list, O, list!" [THHPD I.v.22]
From: Cesar Rabak
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <416EE7B2.2000207@acm.org>
Joe Marshall escreveu:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Pascal Bourguignon wrote:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>
>> ....
>>
>>>>We knew you knew that. c.l.l is, as Rodney would have said, a tough
>>>>crowd. you can count on anything less than rigorously perfect being
>>>>hammered unmercilessly. The upside being that reading c.l.l is a
>>>>continuing education program in a deep language which really requires
>>>>continuing education.
>>>
>>>Which strangely does not have continuations...
>>>
>>
>>Yes, but we handle that case pretty well :)
>
>
> Somebody catch me before this entire thread is thrown into confusion.
Why? Do you think it still did not happen?
Joe Marshall <···@ccs.neu.edu> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Pascal Bourguignon wrote:
> >> Kenny Tilton <·······@nyc.rr.com> writes:
> >>
> > ....
> >>>We knew you knew that. c.l.l is, as Rodney would have said, a tough
> >>>crowd. you can count on anything less than rigorously perfect being
> >>>hammered unmercilessly. The upside being that reading c.l.l is a
> >>>continuing education program in a deep language which really requires
> >>>continuing education.
> >> Which strangely does not have continuations...
> >>
> >
> > Yes, but we handle that case pretty well :)
(catch me
> Somebody catch me before this entire thread is thrown into confusion.
)
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Joe Marshall wrote:
> Duane Rettig <·····@franz.com> writes:
>
>
>>Jon Boone <········@delamancha.org> writes:
>>
>>
>>>Joe Marshall <···@ccs.neu.edu> writes:
>>>
>>>
>>>>Marco Antoniotti <·······@cs.nyu.edu> writes:
>>>>
>>>>
>>>>>Pascal Bourguignon wrote:
>>>>>
>>>>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>>>>
>>>>>
>>>>> ....
>>>>>
>>>>>>>We knew you knew that. c.l.l is, as Rodney would have said, a tough
>>>>>>>crowd. you can count on anything less than rigorously perfect being
>>>>>>>hammered unmercilessly. The upside being that reading c.l.l is a
>>>>>>>continuing education program in a deep language which really requires
>>>>>>>continuing education.
>>>>>>
>>>>>>Which strangely does not have continuations...
>>>>>>
>>>>>
>>>>>Yes, but we handle that case pretty well :)
>>>>
>>>>Somebody catch me before this entire thread is thrown into confusion.
>>>
>>>well, we can TRY
>>
>>EXCEPT ... Oh, never mind.
>
>
> FINALLY, someone gets the joke....
Before, you say this, after, you say that? I have thunk this dynamic
wind is over?!?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Duane Rettig
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <4d5zkq09d.fsf@franz.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Pascal Costanza wrote:
> > Joe Marshall wrote:
>
> >
>
> >> Duane Rettig <·····@franz.com> writes:
> >>
> >>
> >>> Jon Boone <········@delamancha.org> writes:
> >>>
> >>>
> >>>> Joe Marshall <···@ccs.neu.edu> writes:
> >>>>
> >>>>
> >>>>> Marco Antoniotti <·······@cs.nyu.edu> writes:
> >>>>>
> >>>>>
> >>>>>> Pascal Bourguignon wrote:
> >>>>>>
> >>>>>>> Kenny Tilton <·······@nyc.rr.com> writes:
> >>>>>>>
> >>>>>>
> >>>>>> ....
> >>>>>>
> >>>>>>>> We knew you knew that. c.l.l is, as Rodney would have said, a tough
> >>>>>>>> crowd. you can count on anything less than rigorously perfect being
> >>>>>>>> hammered unmercilessly. The upside being that reading c.l.l is a
> >>>>>>>> continuing education program in a deep language which really
> >>>>>>>> requires
>
> >>>>>>>> continuing education.
> >>>>>>>
> >>>>>>>
> >>>>>>> Which strangely does not have continuations...
> >>>>>>>
> >>>>>>
> >>>>>> Yes, but we handle that case pretty well :)
> >>>>>
> >>>>>
> >>>>> Somebody catch me before this entire thread is thrown into confusion.
> >>>>
> >>>>
> >>>> well, we can TRY
> >>>
> >>>
> >>> EXCEPT ... Oh, never mind.
> >>
> >>
> >>
> >> FINALLY, someone gets the joke....
> > Before, you say this, after, you say that? I have thunk this dynamic
> > wind is over?!?
>
>
> some continuation will always be around. and that brings us full loop.
Just quit.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Pascal Costanza wrote:
> > > Joe Marshall wrote:
> >
> > >
> >
> > >> Duane Rettig <·····@franz.com> writes:
> > >>
> > >>
> > >>> Jon Boone <········@delamancha.org> writes:
> > >>>
> > >>>
> > >>>> Joe Marshall <···@ccs.neu.edu> writes:
> > >>>>
> > >>>>
> > >>>>> Marco Antoniotti <·······@cs.nyu.edu> writes:
> > >>>>>
> > >>>>>
> > >>>>>> Pascal Bourguignon wrote:
> > >>>>>>
> > >>>>>>> Kenny Tilton <·······@nyc.rr.com> writes:
> > >>>>>>>
> > >>>>>>
> > >>>>>> ....
> > >>>>>>
> > >>>>>>>> We knew you knew that. c.l.l is, as Rodney would have said, a tough
> > >>>>>>>> crowd. you can count on anything less than rigorously perfect being
> > >>>>>>>> hammered unmercilessly. The upside being that reading c.l.l is a
> > >>>>>>>> continuing education program in a deep language which really
> > >>>>>>>> requires
> >
> > >>>>>>>> continuing education.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Which strangely does not have continuations...
> > >>>>>>>
> > >>>>>>
> > >>>>>> Yes, but we handle that case pretty well :)
> > >>>>>
> > >>>>>
> > >>>>> Somebody catch me before this entire thread is thrown into confusion.
> > >>>>
> > >>>>
> > >>>> well, we can TRY
> > >>>
> > >>>
> > >>> EXCEPT ... Oh, never mind.
> > >>
> > >>
> > >>
> > >> FINALLY, someone gets the joke....
> > > Before, you say this, after, you say that? I have thunk this dynamic
> > > wind is over?!?
> >
> >
> > some continuation will always be around. and that brings us full loop.
>
> Just quit.
Which you can only do in an implementation dependant way, if at all.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
From: Joe Marshall
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <acuocak3.fsf@ccs.neu.edu>
Kenny Tilton <·······@nyc.rr.com> writes:
> Pascal Costanza wrote:
>> Joe Marshall wrote:
>>
>>> Duane Rettig <·····@franz.com> writes:
>>>
>>>
>>>> Jon Boone <········@delamancha.org> writes:
>>>>
>>>>
>>>>> Joe Marshall <···@ccs.neu.edu> writes:
>>>>>
>>>>>
>>>>>> Marco Antoniotti <·······@cs.nyu.edu> writes:
>>>>>>
>>>>>>
>>>>>>> Pascal Bourguignon wrote:
>>>>>>>
>>>>>>>> Kenny Tilton <·······@nyc.rr.com> writes:
>>>>>>>>
>>>>>>>
>>>>>>> ....
>>>>>>>
>>>>>>>>> We knew you knew that. c.l.l is, as Rodney would have said, a tough
>>>>>>>>> crowd. you can count on anything less than rigorously perfect being
>>>>>>>>> hammered unmercilessly. The upside being that reading c.l.l is a
>>>>>>>>> continuing education program in a deep language which really
>>>>>>>>> requires
>>>>>>>>> continuing education.
>>>>>>>>
>>>>>>>>
>>>>>>>> Which strangely does not have continuations...
>>>>>>>>
>>>>>>>
>>>>>>> Yes, but we handle that case pretty well :)
>>>>>>
>>>>>>
>>>>>> Somebody catch me before this entire thread is thrown into confusion.
>>>>>
>>>>>
>>>>> well, we can TRY
>>>>
>>>>
>>>> EXCEPT ... Oh, never mind.
>>>
>>>
>>>
>>> FINALLY, someone gets the joke....
>> Before, you say this, after, you say that? I have thunk this dynamic
>> wind is over?!?
>
> some continuation will always be around. and that brings us full loop.
Some might consider that a moral imperative.
Joe Marshall <···@ccs.neu.edu> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> Pascal Costanza wrote:
>>> Joe Marshall wrote:
>>>
>>>> Duane Rettig <·····@franz.com> writes:
>>>>
>>>>
>>>>> Jon Boone <········@delamancha.org> writes:
>>>>>
>>>>>
>>>>>> Joe Marshall <···@ccs.neu.edu> writes:
>>>>>>
>>>>>>
>>>>>>> Marco Antoniotti <·······@cs.nyu.edu> writes:
>>>>>>>
>>>>>>>
>>>>>>>> Pascal Bourguignon wrote:
>>>>>>>>
>>>>>>>>> Kenny Tilton <·······@nyc.rr.com> writes:
>>>>>>>>>
>>>>>>>>
>>>>>>>> ....
>>>>>>>>
>>>>>>>>>> We knew you knew that. c.l.l is, as Rodney would have said, a tough
>>>>>>>>>> crowd. you can count on anything less than rigorously perfect being
>>>>>>>>>> hammered unmercilessly. The upside being that reading c.l.l is a
>>>>>>>>>> continuing education program in a deep language which really
>>>>>>>>>> requires
>>>>>>>>>> continuing education.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Which strangely does not have continuations...
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, but we handle that case pretty well :)
>>>>>>>
>>>>>>>
>>>>>>> Somebody catch me before this entire thread is thrown into confusion.
>>>>>>
>>>>>>
>>>>>> well, we can TRY
>>>>>
>>>>>
>>>>> EXCEPT ... Oh, never mind.
>>>>
>>>>
>>>>
>>>> FINALLY, someone gets the joke....
>>> Before, you say this, after, you say that? I have thunk this dynamic
>>> wind is over?!?
>>
>> some continuation will always be around. and that brings us full loop.
>
> Some might consider that a moral imperative.
The moral standards of those who deal with unbound sluts are rather low.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Wade Humeniuk
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <7iwcd.21926$z96.17484@clgrps12>
lin8080 wrote:
>
> What I need/wish is a kind of expanded cons-cell like (0.1.1.0) (not
> (0.0).(1.0) things).
> Else I'm looking for a all-around accsess to all "a3, b3, c3.. f3"
> (if-exist) values
> and last an easy way to manipulate single BITs, ie. all a1, a2, ..a6
> mutate to (0.0).
> Maybe the idea using cons.cells is not so good?
They are called bit-vectors.
CL-USER 5 > (bit-and #*0110 #*0000)
#*0000
Wade
lin8080 <·······@freenet.de> writes:
> Well. I have a hang in mind about BIT- structures. Maybe someone could
> point me to any helpfull ideas.
CL-USER> (make-array (list 8 12) :element-type 'bit :initial-element 0)
#2A(#*000000000000
#*000000000000
#*000000000000
#*000000000000
#*000000000000
#*000000000000
#*000000000000
#*000000000000)
CL-USER> (defparameter b1 (make-array (list 8 12)
:element-type 'bit :initial-element 0))
B1
CL-USER> (defparameter b2 (make-array (list 8 12)
:element-type 'bit :initial-element 0))
B2
CL-USER> (loop for i from 0 below 8 do
(loop for j from 0 below i do
(setf (aref b1 i j) 1 (aref b2 i (- 11 j)) 1)))
NIL
CL-USER> b1
#2A(#*000000000000
#*100000000000
#*110000000000
#*111000000000
#*111100000000
#*111110000000
#*111111000000
#*111111100000)
CL-USER> b2
#2A(#*000000000000
#*000000000001
#*000000000011
#*000000000111
#*000000001111
#*000000011111
#*000000111111
#*000001111111)
CL-USER> (bit-ior b1 b2)
#2A(#*000000000000
#*100000000001
#*110000000011
#*111000000111
#*111100001111
#*111110011111
#*111111111111
#*111111111111)
CL-USER>
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
From: lin8080
Subject: Re: Lisp benefits against other functional programming languages
Date:
Message-ID: <41763B24.96C02BFB@freenet.de>
Pascal Bourguignon schrieb:
> lin8080 <·······@freenet.de> writes:
> > Well. I have a hang in mind about BIT- structures. Maybe someone could
> > point me to any helpfull ideas.
> CL-USER> (make-array (list 8 12) :element-type 'bit :initial-element 0)
> #2A(#*000000000000
> #*000000000000
> #*000000000000
> #*000000000000
> #*000000000000
> #*000000000000
> #*000000000000
> #*000000000000)
Thank you.
I test that new path. Using arrays, I come on this thought first, but
mainly I want go also some other ways.
The possibility to expand cons-cells looks very interesting for me, not
only for this case.
stefan