Labels

[Tim Rentsch]

This is why the whole thing has got such an awful reputation. You
write functions to return one and zero, and get them wrong. I
don't think there's any other language where that is possible.

Don't you ever get tired of lecturing people who have a better
understanding of the subject under discussion than you do
yourself?

 

[Kenny McCormack]

Don't you ever get tired of lecturing people who have a better
understanding of the subject under discussion than you do
yourself?

Do you?

--
Is God willing to prevent evil, but not able? Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent.
Is he both able and willing? Then whence cometh evil?
Is he neither able nor willing? Then why call him God?
~ Epicurus

 

[Malcolm McLean]

Do you?

It's a great thing to have a deep understanding of lambda calculus. I've
just got a rough idea of how it works - enough to implement a Lisp interpreter,
and to see how you might set about building an arbitrarily complex function
using just lambdas, but I could never have derived Church's theorem by myself,
and I managed to get the definitions of the natural numbers a bit wrong.

But it's not enough to understand how something works theoretically, you also
need to know how things work practically, and, in programming, what
psychological barriers are in place. That's something a lot of people who
are very good on the theory side of computer science are lacking in.

So we've all got our roles to play. But of course if people can't work in
teams, that makes things difficult. If the reason is superior attitudes,
bullying, sarcasm, etc, rather than bona fide social inadequacy, which
like any other weakness and understanding person will accommodate, then they
are probably best ignored.

 

[Ben Bacarisse]

The irony is that I've written a Lisp interpreter, that is reasonably
functional. I haven't released it, partly because the garbage collection
isn't in yet, but also because I found it almost impossible to write little
test programs for it and work out what the interpreter was supposed
t actually do with them.

How can it be "reasonably functional" and yet "almost impossible to
write little test programs for"?

You probably wrote an interpreter for a tiny Lisp-like language, or
maybe it was just a lambda calculus reduction engine. Just as you can't
claim to have written a C compiler unless it makes a good stab at
implementing some reasonable proportion of the language standard, a Lisp
interpreter must make some stab at implementing the Lisp standard.

I think there's no other language where
the interpreter is easier to write than "hello world".

Now I know you are just winding me up:

(format t "Hello world~%")

If lisp was easy to program, the world would be using Lisp, because the
lambda keyword does have a layer of abstraction that C lacks.

Languages don't succeed or fail based on that that criterion. Of all
the languages I've taught to beginners, Lisp was by far the easiest.

 

[Keith Thompson]

The irony is that I've written a Lisp interpreter, that is reasonably
functional. I haven't released it, partly because the garbage collection
isn't in yet, but also because I found it almost impossible to write little
test programs for it and work out what the interpreter was supposed
t actually do with them. I think there's no other language where
the interpreter is easier to write than "hello world".

Using GNU clisp:

(print "hello world")

See also <http://en.wikibooks.org/wiki/Common_Lisp>.

 

[Ben Bacarisse]

[...] I think there's no other language where
the interpreter is easier to write than "hello world".

Using GNU clisp:

(print "hello world")

That's equivalent to printf("\"hello world\""); (i.e. with quotes and
without the newline) -- not that that is actually wrong as a "hello
word" program. You can replace print with princ to get rid of the
quotes, and you can add the newline literally:

(princ "hello world
")

though I still prefer "format".

<snip>

 

[Keith Thompson]

[...] I think there's no other language where
the interpreter is easier to write than "hello world".

Using GNU clisp:

(print "hello world")

That's equivalent to printf("\"hello world\""); (i.e. with quotes and
without the newline) -- not that that is actually wrong as a "hello
word" program. You can replace print with princ to get rid of the
quotes, and you can add the newline literally:

(princ "hello world
")

though I still prefer "format".

<snip>

It's not *quite* as simple as I thought it was, but no worse than C's
printf vs. puts vs. fputs.

(format t "Hello world~%")

seems to be the most straightforward approach, and very close to C's

printf("Hello world\n");

 

[Ben Bacarisse]

It's not *quite* as simple as I thought it was, but no worse than C's
printf vs. puts vs. fputs.

(format t "Hello world~%")

Seems odd to post this in a reply to me when I posted exactly the same
thing a couple of hours ago. Maybe you have me scored down. Anyway, I
am sure Malcolm is just winding people up -- he must know that printing
"Hello world" is simple in Lisp.

<snip>

 

[Keith Thompson]

Seems odd to post this in a reply to me when I posted exactly the same
thing a couple of hours ago. Maybe you have me scored down.

Certainly not.

I just re-checked your article, to which I was replying. You mentioned
that you prefer "format" over "princ", but you didn't show the full
command using "format".

[...]

 

[Rosario1903]

#include <stdio.h>
#include <stdlib.h>

void testfn (void)
{int i;

i=0;
while (1) {
printf("%d ",i);
if (i==10) break;
if (i==5)
i=i+3;
else
++i;
}
}

yes i would write abova as:
[where "<i" it means push i in the stack and D*s fill the place the
last i in the stack with the chars "%d", 0, 0]

testfnflat:
<i,i
D*s="%d"|i=0
..1: a=s
printf<(a, i)
i==10 #.3
i== 5!#.2|i+=3|#.1
..2: ++i|#.1
..3:

i,i

ret

see how easy is find a good way for indent it...

in few word if() goto, and goto are the key words in the programming
area, so one have to traslate these in one symbols "#"
[few simbols is it possible]

i==10#.3
in C would mean: "if(i==10) goto .3"

i== 5!#.2|i+=3
..2:
in C would mean: "if(i==5 ) i+=3"

void testfnflat (void)
{int i;

i=0; // line 1
L1: // line 2
printf("%d ",i); // line 3
if (i==10) goto L2; // line 4
if (i!=5) goto L3; // line 5
i=i+3; // line 6
goto L4; // line 7

here i would write goto L1

 

[Ben Bacarisse]

Certainly not.

I just re-checked your article, to which I was replying. You mentioned
that you prefer "format" over "princ", but you didn't show the full
command using "format".

I was referring to my first reply to Malcolm.
<0.f8dfff5f031e3ec0d27f.20131112154436GMT.87vbzxr5ej.fsf_-_@bsb.me.uk>

Maybe my changing the thread subject with [OT] messed things up.

 

[Malcolm McLean]

How can it be "reasonably functional" and yet "almost impossible to
write little test programs for"?

Obviously it will parse an arbitrarily complex arithmetical expression,
any halfway competent C programmer can knock that up in a few minutes.

The tricky thing is the lambda

This is a trivial function.

(set (quote foo) (lambda (x y z) (+(* x y) z)) )

so you can't eyeball that and make sure it's right. It's not entirely intuitive
to a human which brackets are needed and which aren't.
So far we're not doing anything that C can't, obviously we need a stack for
scoping x, y, and z, a hunk of code but not too bad.

But the snag is that functions are first class objects, as are lists. So
we can assign to foo(). We can do (set (quote fred) (y x z))

then

( set (quote foo) (lambda fred ( + (* x y) (z) ) )

Should the list that fred is set to have been quoted? How should the interpreter
behave if it hasn't been? How do we cycle fred through all three permutations
of x, y, z by setting a b c to various values of x y z? The difficulty
blows up very quickly.

You very quickly lose track of what ought to be evaluated when, and what the
path through the interpreter ought to be. You can run the code through a
correct Lisp interpreter to check it, but that's sort of cheating. Trying
to work out what a group of expressions should evaluate to by reading Lisp
docs is a nightmare.

 

[Keith Thompson]

Certainly not.

I just re-checked your article, to which I was replying. You mentioned
that you prefer "format" over "princ", but you didn't show the full
command using "format".

I was referring to my first reply to Malcolm.
<0.f8dfff5f031e3ec0d27f.20131112154436GMT.87vbzxr5ej.fsf_-_@bsb.me.uk>

Maybe my changing the thread subject with [OT] messed things up.

I replied to an article of yours in which you mentioned "format" but
didn't show an example. I probably also saw your other article in which
you showed an actual example, but I don't necessarily keep good track of
what I've read. (The "[OT]" did cause my newsreader to show two
separate threads, but I don't think that made any difference.)

 

[Kenny McCormack]

I've only been back a few days and I see the same posturing and Kiki
emulation going on as years ago. I see Tim thinks he's in the c.l.c
elite now. Bless. Montone robotic aloofness that only c.l.c can manage.

It will never chnage. One of my on-going image is of Kiki (and Jimmy, and
the rest of the gang), in their 90s, posting from the nursing home.

Still telling people how to prototype main() and why they shouldn't cast
the return value of malloc()...

--
Here's a simple test for Fox viewers:

1) Sit back, close your eyes, and think (Yes, I know that's hard for you).
2) Think about and imagine all of your ridiculous fantasies about Barack Obama.
3) Now, imagine that he is white. Cogitate on how absurd your fantasies
seem now.

See? That wasn't hard, was it?

 

[Ben Bacarisse]

Obviously it will parse an arbitrarily complex arithmetical expression,
any halfway competent C programmer can knock that up in a few minutes.

The tricky thing is the lambda

This is a trivial function.

(set (quote foo) (lambda (x y z) (+(* x y) z)) )

so you can't eyeball that and make sure it's right. It's not entirely
intuitive to a human which brackets are needed and which aren't.

What are you talking about? Are you trying to explain the behaviour of
your not-Lisp expression evaluator? Why would that be significant here?

So far we're not doing anything that C can't, obviously we need a stack for
scoping x, y, and z, a hunk of code but not too bad.

In Lisp, even (lambda (x y z) (+ (* x y) z)) already goes beyond what C
can do (for example, it's type-generic, and can work with values that C
can't represent natively) but you may be talking about your own,
non-Lisp, interpreter. In which case, I can't what it does.

But the snag is that functions are first class objects, as are lists. So
we can assign to foo(). We can do (set (quote fred) (y x z))

then

( set (quote foo) (lambda fred ( + (* x y) (z) ) )

Should the list that fred is set to have been quoted? How should the
interpreter behave if it hasn't been? How do we cycle fred through all
three permutations of x, y, z by setting a b c to various values of x
y z?

Since this is not Lisp, it's for you to say. You've invented a language
and are writing an interpreter for it. It can work any way you like.

The difficulty blows up very quickly.

You very quickly lose track of what ought to be evaluated when, and what the
path through the interpreter ought to be. You can run the code through a
correct Lisp interpreter to check it, but that's sort of cheating. Trying
to work out what a group of expressions should evaluate to by reading Lisp
docs is a nightmare.

Maybe a book about Lisp would be more approachable?

 

[Malcolm McLean]

Since this is not Lisp, it's for you to say. You've invented a language
and are writing an interpreter for it. It can work any way you like.

I've missed off some closing parentheses. It's impossible to write Lisp
of any length without specialised editing software.
Now is a dynamic argument list allowed? You seem to be implying not, but
I can't find such a restriction, and it seems to go against the spirit
of the language.

 

[Tim Rentsch]

Do you?

Do you find my posting style offensive? If so I would
love to hear any constructive suggestions for how it
might be improved.

 

[Ben Bacarisse]

I've missed off some closing parentheses.

And added some. (z) is wrong.

It's impossible to write Lisp
of any length without specialised editing software.
Now is a dynamic argument list allowed?

Not as you have it, no. Lisp macros, on the other hand, can do almost
anything with the syntax.

You seem to be implying not, but
I can't find such a restriction,

In standard Lisp, a lambda is a "special form" -- a list that has
specified syntax. You should have been able to work that out because
when you wrote (lambda (x y z) (+ (* x y) z)) neither of the two lists
following 'lambda' were evaluated as they would be in a non-special
form.

and it seems to go against the spirit
of the language.

I don't think you have a sound grasp of the spirit of Lisp. It's not a
free-for-all.

 

[Malcolm McLean]

Not as you have it, no. Lisp macros, on the other hand, can do almost
anything with the syntax.


In standard Lisp, a lambda is a "special form" -- a list that has
specified syntax. You should have been able to work that out because

when you wrote (lambda (x y z) (+ (* x y) z)) neither of the two lists
following 'lambda' were evaluated as they would be in a non-special
form.

This is it. It's a lot less regular than it looks and there are many
special cases.
You'd expect (lambda (quote (x y z)) (quote ( +(* x y) z)))))

and it's tempting to regularise the language in that way, so it's then
trivial to implement (lambda fredsarguments fredsfunction).

I think the real problem is that you look at the language and think "OK, I
can knock up an interpreter for this in ten minutes". Then you find you can't
because of rules like that, because the ' isn't just syntactic sugar for (quote ( )) but needs it's own special syntax handler, and the same for deffun,
because z and (z) don't evaluate to the same thing as in C.

Ad as I said, it's a lot more difficult to work out what path a lisp
expression should have through the interpreter than for the equivalent
function in a language like Basic.

 

[Ben Bacarisse]

This is it. It's a lot less regular than it looks and there are many
special cases.

I can see that Lisp can't win. If it has special forms for convenience
(like conditional execution for example) than it's cluttered up with
special cases. If it's stripped back and totally uniform, you'd be
complaining that it's impossible to use -- try writing a conditional
where the form (if test then-form else-form) has uniform evaluation
semantics. Indeed, this was your initial complaint.

You'd expect (lambda (quote (x y z)) (quote ( +(* x y) z)))))
and it's tempting to regularise the language in that way, so it's then
trivial to implement (lambda fredsarguments fredsfunction).

That's a temptation that should be avoided. Programmer productivity and
convenience should trump ease of implementation in the majority of cases.

I think the real problem is that you look at the language and think
"OK, I can knock up an interpreter for this in ten minutes". Then you
find you can't because of rules like that, because the ' isn't just
syntactic sugar for (quote ( )) but needs it's own special syntax
handler, and the same for deffun, because z and (z) don't evaluate to
the same thing as in C.

Well, you do need to know the basic syntax, yes. In Lisp, ()s are used
in a very uniform way -- they just build forms. In C they are used for
all sorts of things: (int)(2 * (f(42) + 1)). There's three different
kinds of bracket in one expression (and, yeah!, a hint of topicality).

Ad as I said, it's a lot more difficult to work out what path a lisp
expression should have through the interpreter than for the equivalent
function in a language like Basic.

The clue is in the name.