Hiya! I'm a first year compsci major okey at Java and C. Rumors of
Lisp's great power and view of programming have enticed me to seek out
guidance on the topic. How should I go about learning this language? Any
stumbling blocks I should be aware of?
Much obliged!
Brendan McClure wrote:
> Hiya! I'm a first year compsci major okey at Java and C. Rumors of
> Lisp's great power and view of programming have enticed me to seek out
> guidance on the topic. How should I go about learning this language?
Since you already know C and Java, I recommend you try Practical Common
Lisp, available as a dead tree book and online as well:
http://www.gigamonkeys.com/book/
I believe that's the best way to get started.
Pedro Kroger
Brendan McClure wrote:
> Hiya! I'm a first year compsci major okey at Java and C. Rumors of
> Lisp's great power and view of programming have enticed me to seek out
> guidance on the topic. How should I go about learning this language? Any
> stumbling blocks I should be aware of?
1. Yeah: this one: (block nil). It invisibly surrounds almost
everything you do, and when you're stuck in some deep nesting, you just
yell (return), perhaps with optional values.
2. What else. If you ever wonder why sometimes the #' is omitted in
#'(lambda (...) ...), it's because lambda is a macro that expands to
(function (lambda ...)).
3. In a function that takes a parameter called f, which is a function,
the reason (f 42) doesn't call that function is that Lisp has separate
function and value bindings for symbols. Use (funcall f 42).
4. (setf *var* 42) to create a variable is undefined behavior. Use
(defvar *var* 42), (defparameter *var* 42).
5. Modifying literals objects is undefined. That holds for lists,
strings, vectors and other objects. Don't do this: (setf (car '(a b))
'd).
6. Everything has a class /and/ type. You can define new methods
specialized over everything. Numbers, strings, symbols, you name it.
7. The object NIL is a symbol. As a value it means false and also empty
list. It can name things sometimes like blocks (see #1). The type
called NIL contains no values. The object NIL itself has type NULL, and
there is a class NULL also. Now cover up this paragraph and repeat what
was written.
8. The double splice operator in a nested backquote ``(... ,@,@expr)
obeys a kind of distributive law. Commas and backticks cancel. Sort of.
9. The format string in a format call can be compiled to code with
FORMATTER: (format t (formatter "~a-~a" 1 2)).
10. Try MACROEXPAND or MACROEXPAND-1 on everything. Don't forget to
quote it. For instance (macroexpand-1 '(formatter "~a-~a"))
Brendan McClure wrote:
> Hiya! I'm a first year compsci major okey at Java and C. Rumors of
> Lisp's great power and view of programming have enticed me to seek out
> guidance on the topic.
Sounds like you do not need: http://wiki.alu.org/RtL_Highlight_Film
> How should I go about learning this language? Any
> stumbling blocks I should be aware of?
The IDEs suck, except for this one: www.franz.com on win32 and Linux
(tho the latter seems experimental). The sucky IDEs are part of our
charm, like having to climb fences and trespass on private property to
get to a great swimming hole.
Lispworks does not oversuck, and can be had on all major platforms. I am
talking about trial versions. The MCL IDE on Mac is pretty good but
lacks a project manager, same for CormanCL on win32. Latter free to try,
I forget where MCL is nowadays on trials.
If you are stuck using "free" stuff, every yobbo from here to Hialeah
fill be falling over themselves to help you get started so I cannot rub
their noses in it.
hth, ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Brendan McClure wrote:
> How should I go about learning this language?
Just find a fun project to work on. You're looking for two things:
macros and functional programming. If you're familiar with C macros,
Lisp macros are similar, except they're a billion times better. Lists
are used frequently, and the list functions are a good place to start
learning about functional programming.
> stumbling blocks I should be aware of?
Interminable discussions on the Usenet :D
--
Dan
www.prairienet.org/~dsb
On Wed, 13 Dec 2006 15:51:46 -0600, Dan Bensen wrote:
> Brendan McClure wrote:
>> How should I go about learning this language?
> Just find a fun project to work on. You're looking for two things:
> macros and functional programming. If you're familiar with C macros,
> Lisp macros are similar, except they're a billion times better.
I disagree here. Lisp macros are fundamentally different from C macros
because C macros don't understand C's syntax and so cannot be used to
extend the language. Lisp macros do and often are.
Lisp does have something somewhat similar to C's macros called
read-macros. Most programmers don't use them very often.
> Lists are used frequently, and the list functions are a good place to
> start learning about functional programming.
This I agree with.
>> stumbling blocks I should be aware of?
> Interminable discussions on the Usenet :D
Right.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Chris Barts wrote:
>> Lisp macros are similar, except they're a billion times better.
> I disagree here. Lisp macros are fundamentally different from C macros
> because C macros don't understand C's syntax and so cannot be used to
> extend the language. Lisp macros do and often are.
C macros can easily be used to extend source-level syntax.
For instance, these two macros can be used for the same purpose in C++
and CL:
#define foreach_widget(N) for(int N=0; N<NumWidgets; N++)
(defmacro foreach-widget (n &body body)
`(dotimes (,n num-widgets 'nil) ,@body))
A C programmer who knows C macros can use Lisp macros in a similar way.
--
Dan
www.prairienet.org/~dsb
Dan Bensen wrote:
> Chris Barts wrote:
>
>>> Lisp macros are similar, except they're a billion times better.
>
> > I disagree here. Lisp macros are fundamentally different from C macros
> > because C macros don't understand C's syntax and so cannot be used to
> > extend the language. Lisp macros do and often are.
>
> C macros can easily be used to extend source-level syntax.
> For instance, these two macros can be used for the same purpose in C++
> and CL:
>
> #define foreach_widget(N) for(int N=0; N<NumWidgets; N++)
Yeah, but that is still textual* so one only gets as far as one can get
with a GREPpy text replace operation, which does not include, say,
wrapping the foreach_widget /body/ in a larger form.
But you are right...
>
> (defmacro foreach-widget (n &body body)
> `(dotimes (,n num-widgets 'nil) ,@body))
>
> A C programmer who knows C macros can use Lisp macros in a similar way.
>
...and does not have to sold on the value of Lisp macros, unlike the
users of certain other languages who will go nameless (Python).
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Dec 13, 11:35 pm, Dan Bensen <··········@cyberspace.net> wrote:
>
> A C programmer who knows C macros can use Lisp macros in a similar way.
Hmmm. A C programmer who REALLY knows C macros _stops_ using them. :)
I don't think that's the message you want to give.
Ben wrote:
> On Dec 13, 11:35 pm, Dan Bensen <··········@cyberspace.net> wrote:
>
>>A C programmer who knows C macros can use Lisp macros in a similar way.
>
>
>
> Hmmm. A C programmer who REALLY knows C macros _stops_ using them. :)
> I don't think that's the message you want to give.
A good programmer does not shy away from powerful tools, they master
them. And periodically misfire and drive a nail into their skull. Might
be the worst bug I ever created, a side-effect as an arg to a C macro
that got reference more than once. Five days to find, IIRC. Enough topay
for Lispworks Pro. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> be the worst bug I ever created, a side-effect as an arg to a C macro
> that got reference more than once.
I've had more trouble with (carelessly abusing) C++ scoping than with
macros. If you have a complex looping pattern that has to be repeated,
it's nice to have a DO_THIS_REALLY_IMPORTANT_LOOP macro so you don't
have to maintain each instance of it separately.
--
Dan
www.prairienet.org/~dsb
Dan Bensen wrote:
> Ken Tilton wrote:
>
>> be the worst bug I ever created, a side-effect as an arg to a C macro
>> that got reference more than once.
>
> I've had more trouble with (carelessly abusing) C++ scoping than with
> macros. If you have a complex looping pattern that has to be repeated,
> it's nice to have a DO_THIS_REALLY_IMPORTANT_LOOP macro so you don't
> have to maintain each instance of it separately.
>
Indeed. You all will recall i started this project with an exploration
of a possible quick win: automatically translating my C version from the
90s to Lisp via Antlr. Something Wonderful emerged, tho in the end I
decided NIH applied even to my own code and rewrote the thing from
scratch: it turns out I had used macros for everything, effectively
building up C to my domain problem! Well, kinda. But every destruct
member access had its own little macro, so there was almost no -> or
(*). stuff to be found. And that meant that I had in effect anticipated
CLOS and structure slot accessors. By hiding all those macros from Antlr
(commenting them out) the parser generated function calls everywhere,
even, yes, for the several iterators that were ubiquitous throughout my
code.
Which is why I found it funny to read that C macros were avoided by good
programmers.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ben wrote:
> Hmmm. A C programmer who REALLY knows C macros _stops_ using them. :)
A REAL C programmer uses them judiciously, just as a Lisp programmer does.
> I don't think that's the message you want to give.
My message is that anyone who likes macros will love Lisp.
They solve some of the same problems that C macros address,
but they do it vastly better.
--
Dan
www.prairienet.org/~dsb
Chris Barts <··············@tznvy.pbz> writes:
> On Wed, 13 Dec 2006 15:51:46 -0600, Dan Bensen wrote:
> ...
>> Just find a fun project to work on. You're looking for two things:
>> macros and functional programming. If you're familiar with C macros,
>> Lisp macros are similar, except they're a billion times better.
>
> I disagree here. Lisp macros are fundamentally different from C macros
> because C macros don't understand C's syntax and so cannot be used to
> extend the language. Lisp macros do and often are.
>
The fundamental difference seems to be that C macros produce source
code, while Lisp macros produce tokens. I.e. C macros work before the
code is tokenized, while Lisp macros transform the token stream that
comes out from the reader.
I found it interesting to compare this with languages such as TeX or
PostScript.
--
hw
My correct address is `flowh' in front of at sign and `t-online.de'.
Heinrich Wolf wrote:
> Chris Barts <··············@tznvy.pbz> writes:
>
> > On Wed, 13 Dec 2006 15:51:46 -0600, Dan Bensen wrote:
> > ...
> >> Just find a fun project to work on. You're looking for two things:
> >> macros and functional programming. If you're familiar with C macros,
> >> Lisp macros are similar, except they're a billion times better.
> >
> > I disagree here. Lisp macros are fundamentally different from C macros
> > because C macros don't understand C's syntax and so cannot be used to
> > extend the language. Lisp macros do and often are.
> >
>
> The fundamental difference seems to be that C macros produce source
> code, while Lisp macros produce tokens.
That's backwards. C macros produce (sequences of) preprocessor tokens,
which are not necessarily valid source code even at the lexical level.
Lisp macros reliably produce source code (in the sense of regarding
objects to be source code).
> I.e. C macros work before the
> code is tokenized, while Lisp macros transform the token stream that
> comes out from the reader.
C macros work after the translation phase which decomposes the input
into preprocessor tokens. However, there is second level of token
comprehension whereby preprocessor tokens are reinterpreted as tokens.
At this stage, C has undefined behaviors with regard to preprocessor
tokens which are invalid syntax.
Preprocessing happens in terms of tokens. For instance the token
pasting operator ## has the restriction that its result must be a valid
token. Essentially it takes two tokens, converts them back into raw
text and pastes them together. If the result doesn't have the lexical
syntax of a valid token, the behavior is undefined.
Lisp macros do not transform a token stream; they are functions that
work with atoms and lists. A macro call like (loop for x below 10) is a
function which takes the object (loop for x below 10), analyzes it, and
produces a different object which is substituted in its place.
Lisp read macros do not transform a token stream either; they are
responsible for actually performing the I/O on the raw text stream and
do the tokenizing themselves (or else recurse into the reader API to
pull out objects). The output of a read macro is an object, rather than
tokens. So any token representation of the input is only temporarily
established within the read macro.
On 9688 day of my life Heinrich Wolf wrote:
> The fundamental difference seems to be that C macros produce source
> code, while Lisp macros produce tokens. I.e. C macros work before the
> code is tokenized, while Lisp macros transform the token stream that
> comes out from the reader.
I think most fundamental difference is that C macros just do
substitution, while Lisp macros are _arbitrary functions_ that
transform some data (be it chunks of Lisp code, some domain-specific
language defined by the macro or something else) into code.
Everything else is implementation detail :)
--
Ivan Boldyrev
Is 'evening' a gerund?
Heinrich Wolf <········@willis-werkstaette.de> writes:
> Chris Barts <··············@tznvy.pbz> writes:
>
> > On Wed, 13 Dec 2006 15:51:46 -0600, Dan Bensen wrote:
> > ...
> >> Just find a fun project to work on. You're looking for two things:
> >> macros and functional programming. If you're familiar with C macros,
> >> Lisp macros are similar, except they're a billion times better.
> >
> > I disagree here. Lisp macros are fundamentally different from C macros
> > because C macros don't understand C's syntax and so cannot be used to
> > extend the language. Lisp macros do and often are.
> >
>
> The fundamental difference seems to be that C macros produce source
> code, while Lisp macros produce tokens.
No. The fundamental difference is that C macros are preprocessor
implmented textual substitution, while Lisp macros are Lisp
_functions_ which can make use of the full language, its environment,
etc to do anything a normal function could do, but just at a different
invocation time (macro expansion time), and without the evaluation of
the arguments at point of call. That's it.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com