In article <····························@posting.google.com>, Chessucat wrote:
> (rplacd (quote defun) (quote (fexpr (lambda (x a) (rplacd (car x)
Very, very old Lisp code?
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche <······@cartan.de> writes:
> In article <····························@posting.google.com>, Chessucat wrote:
> > (rplacd (quote defun) (quote (fexpr (lambda (x a) (rplacd (car x)
> > (list (quote expr) (cons (quote lambda) (cdr x))))))))
> Very, very old Lisp code?
Probably.
RPLACD of a symbol used to be the same as SETPLIST.
Not the preferred way to add a property since it bashes all the others.
A FEXPR was a function of a single argument, the unevaluated arglist
(the cdr of the source form). I'm not sure about the A argument
there, which must be an environment (probably in alist form). Maybe
I'm misrembering Maclisp and it allowed this, or this is just
something in the same family. When compiled, it was put on an FSUBR
property instead, btw.
An EXPR was a function of normal function.
In both EXPR and FEXPR cases, you stored a literal lambda, which is no
longer a valid function. But approximately, in modern terms, the above
gibberish says the following, if you imagine a
declare-special-operator-for-interpreter
that works in the 'obvious' way [and would have to have compiler support
separately declared]:
(declare-special-operator-for-interpreter 'defun
#'(lambda (form env)
(declare (ignore env))
(setf (symbol-function (car form))
(eval ; not needed back then, so not present
(cons 'lambda (cdr form))))))
But although people do sometimes romanticize about how Lisp used to be
simple and all we've done is hair it up, people really did often write
code like that stuff above. Because they had neither the tools nor
the culture of abstraction. Being a 'good programmer' at that time
relied on learning all the strange idioms... Today we program in more
straightforward ways, but still somehow find ways to confuse ourselves
and introduce bugs. We call that progress. Heh...
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
>
> Probably.
>
> RPLACD of a symbol used to be the same as SETPLIST.
>
> Not the preferred way to add a property since it bashes all the others.
>
> A FEXPR was a function of a single argument, the unevaluated arglist
> (the cdr of the source form). I'm not sure about the A argument
> there, which must be an environment (probably in alist form). Maybe
> I'm misrembering Maclisp and it allowed this, or this is just
> something in the same family. When compiled, it was put on an FSUBR
> property instead, btw.
>
> An EXPR was a function of normal function.
>
> In both EXPR and FEXPR cases, you stored a literal lambda, which is no
> longer a valid function. But approximately, in modern terms, the above
> gibberish says the following, if you imagine a
> declare-special-operator-for-interpreter
> that works in the 'obvious' way [and would have to have compiler support
> separately declared]:
>
> (declare-special-operator-for-interpreter 'defun
> #'(lambda (form env)
> (declare (ignore env))
> (setf (symbol-function (car form))
> (eval ; not needed back then, so not present
> (cons 'lambda (cdr form))))))
>
> But although people do sometimes romanticize about how Lisp used to be
> simple and all we've done is hair it up, people really did often write
> code like that stuff above. Because they had neither the tools nor
> the culture of abstraction. Being a 'good programmer' at that time
> relied on learning all the strange idioms... Today we program in more
> straightforward ways, but still somehow find ways to confuse ourselves
> and introduce bugs. We call that progress. Heh...
It is all very confusing! I think I'll just stick with BASIC and
maybe C for now. Although, Python look somewhat easy. Computer
programming is hard! So many varibles to control and functions to
write. I wish computer programming is like building a project with
Lego, as when I was a kid. Create a totally independent functions and
hook 'em together and when You don't need a particular function in
your program, just unhook it and tie the remaining end together. Like
one long chain! Have program object be define like a noun that have
certain adjectives that are inherited from it's parent and act with
certain verbs.
Selah,
Chess
>
> It is all very confusing! I think I'll just stick with BASIC and
> maybe C for now. Although, Python look somewhat easy. Computer
> programming is hard! So many varibles to control and functions to
> write. I wish computer programming is like building a project with
> Lego, as when I was a kid. Create a totally independent functions and
> hook 'em together and when You don't need a particular function in
> your program, just unhook it and tie the remaining end together. Like
> one long chain! Have program object be define like a noun that have
> certain adjectives that are inherited from it's parent and act with
> certain verbs.
>
interesting thought (though I had forgot that my keyboard was dvorak before
reply...).
I guess it could be done if the language worked in a trigger/catch manner
(something tries to call a function and if it doesn't exist nothing
happens). like basic undefined variables just appear, though maybe they can
dissapear when the defining form is left.
I didn't really understand what was meant by the last one...
sorry I can't write more but this layout is difficult for me (though I seem
to be developing touch typing for some reason... oddly it seems to be
developing more naturally than my normal style...).
lots of things I consider a lot harder than programming, except maybe with
this keyboard...
--
<·······@hotmail.com> <http://bgb1.hypermart.net/>
·········@yahoo.com (Chessucat) writes:
> It is all very confusing! I think I'll just stick with BASIC and
> maybe C for now. [....]
The post you are commenting on was an _extremely_ obscure program written
in a very old dialect of Lisp. Forming a judgment about Lisp based on this
is like my forming a judgment about C based on the annual obfuscated C
contest...
·········@yahoo.com (Chessucat) writes:
>
> It is all very confusing!
Well for learning Lisp you don't have to learn the not so obvious
thing till you neeed them.
> I think I'll just stick with BASIC and
> maybe C for now.
Well if you found Lisp confusing how about memory handling in C? This
is really problematic.
Why don't you do yourself a favor and write down
A thing which transforms an element of an container (be it an array or
List) and puts the result in another container (a thing which happens
so often that you can not get away without having something like that.
This is a C way
Let's see how much you have to know to get it "somewhat working"
I just drop in comments
#include <stdio.h>
#include <stdlib.h>
/* prototyps */
int add_one (int);
int print_fun (int);
int *make_array(int);
int* map (int* field, int size, int (*map_fun) (int)){
/* int (*map_fun) (int) is a pointer to a function yielding an
int and expectign an int as parameter*/
int *result = make_array(size);
int i = 0;
for (i = 0; i < size; ++i){
result[i] = map_fun(field[i]);
}
return result;
}
/* this is a function that fullfills the required
third parameter from map */
int add_one (int i){
return ++i;
}
/* see comment to add_one */
int print_fun(int i){
printf("%d, ", i);
return i;
}
int* make_array (int size){
int *result = malloc(size * sizeof (*result));
/* yes it's up to you to get this memory handling right */
if (!result){
/* will you not forget to check? */
fprintf(stderr, "Could not allocate memory, giving up\n");
exit (EXIT_FAILURE);
}
return result; // just come here if memory allocation has succeeded
}
int main (void){
int size = 5;
int *field = NULL;
int *field_after_map = NULL;
int *other_field = NULL;
int i = 0;
field = make_array(size);
for (i = 0; i < size; ++i){
field[i] = i;
}
field_after_map = map (field, size, print_fun);
fputc('\n', stdout);
free(field_after_map); /* what do you have if you forget this
line? */
field_after_map = map (field, size, add_one);
other_field = map (field_after_map, size, print_fun);
fputc('\n', stdout);
free(field);
free(field_after_map);
free(other_field);
return 0;
}
I showed you a way of doing it in C. Useful and re-usable functions
are "just" map, and make_array
Shortcomings.
a) map is not generic that means it just works for fields with integer
b) you have to carry around an extra parameter or you have to think
about how to indicate that you are a the end of a field
c) you must be sure that you free needed memory
d) you have to name all the things you want to hand over to map
Now the Lisp Way
(map 'vector #'(lambda (n) (1+ n)) #(1 2 3 4))
Of course it's a bit unfair. You may use C-libraries in which you have
such things, but there is not standard for that. Main points still
persist.
a) genericity is doable but quite some work in C
b) memory management is always problematic
Well Lisp functions can be developed independendly from other
things. They can be tested out and they can easily put together as you
see in the example.
python offers some advantages of Lisp. But not all....
> Create a totally independent functions and
> hook 'em together and when You don't need a particular function in
> your program, just unhook it and tie the remaining end together. Like
> one long chain!
Do you think you got this independence in C or Basic more than in Lisp?
Have a nice weekend
Friedrich
"Chessucat" <·········@yahoo.com> wrote in message
·································@posting.google.com...
> I wish computer programming is like building a project with
> Lego, as when I was a kid. Create a totally independent functions and
> hook 'em together and when You don't need a particular function in
> your program, just unhook it and tie the remaining end together.
That would be just about the perfect language. One thing though,
you need to be able to manufacture your own Legos, and the device
for doing so ought to be made from standard 2x4 Lego bricks.
> Computer programming is hard!
Yes, it is very hard. I've seen one report that says that
only 1 in 6 `IT applications' (by which I think they mean
database client application deployed on a company-wide
level) come in on time and on budget.
Most people who are paid to develop software have little
or no training and absolutely no clue what they are doing.
But the demand for software is so high, that equiping a
million monkeys with keyboards, Windows XP, and a copy
of `Learn C# in 21 Days', is a workable strategy for many
companies. The bulk of the software thus developed is no
worse than average, and with luck, some might be better.
> I think I'll just stick with BASIC and maybe C for now.
I don't want to give you career advice, but now that you've
seen what exists beyond the walls of Visual Basic, are you
sure you want to stay in the room with the monkeys?
Quoth Joe Marshall:
> [...] are you sure you want to stay in the room with the monkeys?
Sir, I object! Let not the reputation of monkeys everywhere be sullied
by the behavior of a mere few with keyboards and copies of "Teach
Yourself C# in 21 Days".
Please see our open letter at
http://www.nytimes.com/2002/04/14/weekinreview/_14ZELLER.html.
Respectfully yours,
Ben
S.I.M.I.A.N. factotum-at-large
"Ben Goetter" <·······@mazama.net.xyz> wrote in message
·················@216.39.136.5...
> Quoth Joe Marshall:
> > [...] are you sure you want to stay in the room with the monkeys?
>
> Sir, I object! Let not the reputation of monkeys everywhere be sullied
> by the behavior of a mere few with keyboards and copies of "Teach
> Yourself C# in 21 Days".
>
> Please see our open letter at
> http://www.nytimes.com/2002/04/14/weekinreview/_14ZELLER.html.
>
> Respectfully yours,
> Ben
> S.I.M.I.A.N. factotum-at-large
I apologize.
Not out of respect, mind you, I just don't want you throwing
feces at me.
·········@yahoo.com (Chessucat) wrote in message news:<····························@posting.google.com>...
> [...]
must be the original LISP or version 1.5 or something
at least i recognize the commands...
nice to see some code from around 1960 or so... :)
bladerdiebladerdeeg,
Ruliz
·······@roelisch.tmfweb.nl (Ruliz Galaxor) writes:
> ·········@yahoo.com (Chessucat) wrote in message news:<····························@posting.google.com>...
> > [...]
> must be the original LISP or version 1.5 or something
> at least i recognize the commands...
>
> nice to see some code from around 1960 or so... :)
Code like that was still in common use up to the late 1979's actually.