Hai everyone,
it seems like that most of your must have heard of me now, i am
"arnuld", who posted many (2-5) questions here and of course i got no
general answers but very specific answers according to my needs , i
felt hapy evertime i got such *respected* response. i have also posted
answers to peopl'e problems but only occasionaly as my knowledge is not
so wide. upto now i am here from last 8-10 months. i have a good time
here as usually i search the archives once a week and get something
learned. now i have some problem and i searched the whole GOOGLE.GROUPS
and GOOGLE too but did not get the information i needed, so in the end
i posted my question here. i know it is not a right place but i do not
know any other place providing good information, anyway i have posted
it also on comp.programming:
AIM:- i want to work on a project. i have no idea of which project to
choose because i do not have any information regarding different fields
of programming. i want to know
a.) what are these different fields
b.) intensity of career opprtunities in them in next 5 years:
1.) Embedded programing / languages
2.) Ebedded OSs
3.) Server based software (like VIAWEB of Paul Graham)
4.) web applications
5.) web develoment
6.) OS programing
7.) Databases like PG, MySQL, CLSQL etc.
8.) other interesting fields
presently i am learning LISP, working on ch-8 of PCL (MACROS are vary
hard to understand and much harder to write). i have been through
TOURETZKY. i was completely a newbie before that.
i want to choose an open-source project to work on for free( for
experience). second, i am jobless, 3rd i want to choose a project based
on my interest in the field, that is wahy i need to know those 2 things
i have asked to you.
i know folks here have less time and they are not paid to give answers.
In turn all i can do is to start providing help to people on
newsgroups as soon as i get experience of programming. well i respect
Hacker ethics. i will keep on doing work for open-source softwares
(epecially GPLed).
I will appreciate any kind of help.
thanks for your precious time.
-- arnuld
arnuld wrote:
> i want to choose an open-source project to work on for free( for
> experience). second, i am jobless, 3rd i want to choose a project based
> on my interest in the field, that is wahy i need to know those 2 things
> i have asked to you.
Have you checked out
<http://www.lispniks.com/cl-gardeners/> ?
--
Jens Axel S�gaard
> Have you checked out
> <http://www.lispniks.com/cl-gardeners/> ?
yes, after told by you, it is great, rust me. i found it attractive.
thank you.
how about, information regarding embedded OS etc. ?
-- arnuld
"arnuld" <·······@gmail.com> writes:
> (MACROS are vary hard to understand and much harder to write).
No, not really. There's no mystery in them.
Macros are mere functions that take a list and return a form.
A form is either an atom or a list.
For example, we'll write a COND macro, which will transform lists like:
(cond ((= a 1) (print 1))
((= b 2) (print 2) (print a))
(t (print 0)))
into lists like:
(if (= a 1)
(print 1)
(if (= b 2)
(progn (print 2)
(print a))
(print 0)))
Let's write a function that we will call as:
(fmycond '(cond ((= a 1) (print 1))
((= b 2) (print 2) (print a))
(t (print 0))))
to produce this result:
(defun fmycond (whole)
(let* ((clauses (reverse (rest whole)))
(else (if (eql 't (first (first clauses)))
(let ((clause (pop clauses)))
(if (null (rest (rest clause)))
(second clause)
(cons 'progn (rest clause))))
nil)))
(loop for clause in clauses
do (setf else (list 'if (first clause)
(if (null (rest (rest clause)))
(second clause)
(cons 'progn (rest clause)))
else))
finally (return else))))
(fmycond '(cond ((= a 1) (print 1))
((= b 2) (print 2) (print a))
(t (print 0))))
--> (IF (= A 1) (PRINT 1) (IF (= B 2) (PROGN (PRINT 2) (PRINT A)) (PRINT 0)))
Now, we just want to let know to the compiler that this function must
be called to process the COND forms we put in your programs:
(shadow 'cond) ; because it already exist in CL...
(defmacro cond (&whole whole &rest clauses)
(declare (ignore clauses))
(fmycond whole))
(macroexpand-1 '(cond ((= a 1) (print 1))
((= b 2) (print 2) (print a))
(t (print 0))))
-->
(IF (= A 1) (PRINT 1) (IF (= B 2) (PROGN (PRINT 2) (PRINT A)) (PRINT 0))) ;
T
(let ((a 3) (b 2))
(cond ((= a 1) (print 1))
((= b 2) (print 2) (print a))
(t (print 0))))
prints:
2
3
returns:
3
Ok? Nothing special with macros.
Now, we can optimize it a little. As you can see, the lambda list of
the defmacro, is used to destructure the source list. So you don't
have to do it again in your function, and in general, we don't need to
keep the whole source list.
(defmacro cond (&rest clauses)
(fmycond clauses))
(defun fmycond (clauses)
(let* ((clauses (reverse clauses)) ; not (rest whole)
(else (if (eql 't (first (first clauses)))
(let ((clause (pop clauses)))
(if (null (rest (rest clause)))
(second clause)
(cons 'progn (rest clause))))
nil)))
(loop for clause in clauses
do (setf else (list 'if (first clause)
(if (null (rest (rest clause)))
(second clause)
(cons 'progn (rest clause)))
else))
finally (return else))))
And of course, when you have a function that just call another, and
you don't really need the other, you can move the code from the other
to the one:
(defmacro cond (&rest clauses)
(let* ((clauses (reverse clauses))
(else (if (eql 't (first (first clauses)))
(let ((clause (pop clauses)))
(if (null (rest (rest clause)))
(second clause)
(cons 'progn (rest clause))))
nil)))
(loop for clause in clauses
do (setf else (list 'if (first clause)
(if (null (rest (rest clause)))
(second clause)
(cons 'progn (rest clause)))
else))
finally (return else))))
(macroexpand-1 '(cond ((= a 1) (print 1))
((= b 2) (print 2) (print a))
(t (print 0))))
-->
(IF (= A 1) (PRINT 1) (IF (= B 2) (PROGN (PRINT 2) (PRINT A)) (PRINT 0))) ;
T
No mystery.
One final point. Since we are building a lot of new lists (and
sublists) in this kind of functions (the kind of functions that build
lists, this has nothing to do with macros), we can use a shortcut
notation instead of using all these LIST and CONS function calls:
(cons 'progn (rest clause))
can be written as:
`(progn ,@(rest clause))
(list 'if (first clause)
(if (null (rest (rest clause)))
(second clause)
(cons 'progn (rest clause)))
else)
can be written as:
`(if ,(first clause)
,(if (null (rest (rest clause)))
(second clause)
`(progn ,@(rest clause)))
,else)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You question the worthiness of my code? I should kill you where you
stand!"
Pascal Bourguignon wrote:
> "arnuld" <·······@gmail.com> writes:
>
>>(MACROS are vary hard to understand and much harder to write).
>
>
> No, not really. There's no mystery in them.
heh-heh, actually, they are a lot harder than regular code. Reminds me
of EDT on VAX/VMS with its keyboard macro thing. It seems like it took
forever before I got fluent at them, but once I was, woo-hoo!
Once had this gorgeous fellow programmer who had accidentally deleted
every version -- no, so we were not using CMS -- of some big cobol
source (a big one) and could find only a listing file, fortunately
current. Steve came to me near tears because word had gotten out that I
had for some bizarre reason developed the ability to type in a
twenty-command macro almost as fast as if i were doing the editing live.
(it was this weird "watch me" macro trainer that did not actually watch
you edit, it made you imagine you were editing). Anyway, months of
agonizing macro practice finally paid off by five hot minutes
thigh-to-thigh with Steve.
Same thing with Lisp macros. Excruciating at first, then one blessed day
it seems like there is no mystery to them.
:)
ken
Ken Tilton <·········@gmail.com> writes:
> Pascal Bourguignon wrote:
>> "arnuld" <·······@gmail.com> writes:
>>
>>>(MACROS are vary hard to understand and much harder to write).
>> No, not really. There's no mystery in them.
>
> heh-heh, actually, they are a lot harder than regular code. Reminds me
> of EDT on VAX/VMS with its keyboard macro thing. It seems like it took
> forever before I got fluent at them, but once I was, woo-hoo!
>
> Once had this gorgeous fellow programmer who had accidentally deleted
> every version -- no, so we were not using CMS -- of some big cobol
> source (a big one) and could find only a listing file, fortunately
> current. Steve came to me near tears because word had gotten out that
> I had for some bizarre reason developed the ability to type in a
> twenty-command macro almost as fast as if i were doing the editing
> live. (it was this weird "watch me" macro trainer that did not
> actually watch you edit, it made you imagine you were
> editing). Anyway, months of agonizing macro practice finally paid off
> by five hot minutes thigh-to-thigh with Steve.
>
> Same thing with Lisp macros. Excruciating at first, then one blessed
> day it seems like there is no mystery to them.
>
> :)
>
> ken
I think my point is that macro may look complex because you use a lot
of things at once:
- destructuring of the arguments,
- declaration for the compiler,
- function to process and generate a new list,
(including possibly tree waking, recursive functions, etc),
- backquote shortcut.
but each of these are orthogonal, can be teached separately and offer
little difficulty.
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
Pascal Bourguignon wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>Pascal Bourguignon wrote:
>>
>>>"arnuld" <·······@gmail.com> writes:
>>>
>>>
>>>>(MACROS are vary hard to understand and much harder to write).
>>>
>>>No, not really. There's no mystery in them.
>>
>>heh-heh, actually, they are a lot harder than regular code. Reminds me
>>of EDT on VAX/VMS with its keyboard macro thing. It seems like it took
>>forever before I got fluent at them, but once I was, woo-hoo!
>>
>>Once had this gorgeous fellow programmer who had accidentally deleted
>>every version -- no, so we were not using CMS -- of some big cobol
>>source (a big one) and could find only a listing file, fortunately
>>current. Steve came to me near tears because word had gotten out that
>>I had for some bizarre reason developed the ability to type in a
>>twenty-command macro almost as fast as if i were doing the editing
>>live. (it was this weird "watch me" macro trainer that did not
>>actually watch you edit, it made you imagine you were
>>editing). Anyway, months of agonizing macro practice finally paid off
>>by five hot minutes thigh-to-thigh with Steve.
>>
>>Same thing with Lisp macros. Excruciating at first, then one blessed
>>day it seems like there is no mystery to them.
>>
>>:)
>>
>>ken
>
>
> I think my point is that macro may look complex because you use a lot
> of things at once:
>
> - destructuring of the arguments,
> - declaration for the compiler,
> - function to process and generate a new list,
> (including possibly tree waking, recursive functions, etc),
> - backquote shortcut.
>
> but each of these are orthogonal, can be teached separately and offer
> little difficulty.
>
You left out the fact that one is operating on two levels at once, and
the first level (manipulating source code programmatically) is one a
newby macro writer has never before encountered. Big difficulty.
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton <·········@gmail.com> writes:
> You left out the fact that one is operating on two levels at once, and
> the first level (manipulating source code programmatically) is one a
> newby macro writer has never before encountered. Big difficulty.
This is a false problem.
In lisp, code = data means that there's only one level here.
Where do you see _code_ here?
(fmycond '(cond ((= a 1) (print 1))
((= b 2) (print 2) (print a))
(t (print 0))))
--> (IF (= A 1) (PRINT 1) (IF (= B 2) (PROGN (PRINT 2) (PRINT A)) (PRINT 0)))
I see only data, and there is only data!
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Pascal Bourguignon wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>You left out the fact that one is operating on two levels at once, and
>>the first level (manipulating source code programmatically) is one a
>>newby macro writer has never before encountered. Big difficulty.
>
>
> This is a false problem.
> In lisp, code = data means that there's only one level here.
>
> Where do you see _code_ here?
>
> (fmycond '(cond ((= a 1) (print 1))
> ((= b 2) (print 2) (print a))
> (t (print 0))))
> --> (IF (= A 1) (PRINT 1) (IF (= B 2) (PROGN (PRINT 2) (PRINT A)) (PRINT 0)))
>
> I see only data, and there is only data!
>
A good teacher remembers what it was like /before/ they knew how to do
what they are teaching. And the last thing they do is say, "Oh, come on,
this is easy." My 2c, anyway.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton <·········@gmail.com> writes:
> Pascal Bourguignon wrote:
>> Ken Tilton <·········@gmail.com> writes:
>>
>>>You left out the fact that one is operating on two levels at once, and
>>>the first level (manipulating source code programmatically) is one a
>>>newby macro writer has never before encountered. Big difficulty.
>> This is a false problem. In lisp, code = data means that there's
>> only one level here.
>> Where do you see _code_ here?
>> (fmycond '(cond ((= a 1) (print 1))
>> ((= b 2) (print 2) (print a))
>> (t (print 0))))
>> --> (IF (= A 1) (PRINT 1) (IF (= B 2) (PROGN (PRINT 2) (PRINT A)) (PRINT 0)))
>> I see only data, and there is only data!
>>
>
> A good teacher remembers what it was like /before/ they knew how to do
> what they are teaching. And the last thing they do is say, "Oh, come
> on, this is easy." My 2c, anyway.
1- it's really not that hard.
2- psychologically, it's better not to affraid people.
Read: http://www.gnu.org/gnu/rms-lisp.html
Multics Emacs proved to be a great success -- programming new
editing commands was so convenient that even the secretaries in
his office started learning how to use it. They used a manual
someone had written which showed how to extend Emacs, but
didn't say it was a programming. So the secretaries, who
believed they couldn't do programming, weren't scared off. They
read the manual, discovered they could do useful things and
they learned to program.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pascal Bourguignon wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>Pascal Bourguignon wrote:
>>
>>>Ken Tilton <·········@gmail.com> writes:
>>>
>>>
>>>>You left out the fact that one is operating on two levels at once, and
>>>>the first level (manipulating source code programmatically) is one a
>>>>newby macro writer has never before encountered. Big difficulty.
>>>
>>>This is a false problem. In lisp, code = data means that there's
>>>only one level here.
>>>Where do you see _code_ here?
>>>(fmycond '(cond ((= a 1) (print 1))
>>> ((= b 2) (print 2) (print a))
>>> (t (print 0))))
>>>--> (IF (= A 1) (PRINT 1) (IF (= B 2) (PROGN (PRINT 2) (PRINT A)) (PRINT 0)))
>>>I see only data, and there is only data!
>>>
>>
>>A good teacher remembers what it was like /before/ they knew how to do
>>what they are teaching. And the last thing they do is say, "Oh, come
>>on, this is easy." My 2c, anyway.
>
>
> 1- it's really not that hard.
>
> 2- psychologically, it's better not to affraid people.
> Read: http://www.gnu.org/gnu/rms-lisp.html
>
> Multics Emacs proved to be a great success -- programming new
> editing commands was so convenient that even the secretaries in
> his office started learning how to use it. They used a manual
> someone had written which showed how to extend Emacs, but
> didn't say it was a programming. So the secretaries, who
> believed they couldn't do programming, weren't scared off. They
> read the manual, discovered they could do useful things and
> they learned to program.
>
So you are saying I should have shooed Steve away with "Do it yourself!
EDT macros are easy!"? Did I mention she was gorgeous? Anyway...
Sorry, you must be an academic, you know nothing about teaching. :)
kt
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
"Ken Tilton" <·········@gmail.com> wrote in message
·····················@fe12.lga...
> So you are saying I should have shooed Steve away with "Do it yourself!
> EDT macros are easy!"? Did I mention she was gorgeous? Anyway...
You did, but you did not mention she was a woman. I thought I had just
gotten a very personal insight into Kenny.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Coby Beck wrote:
> "Ken Tilton" <·········@gmail.com> wrote in message
> ·····················@fe12.lga...
>
>>So you are saying I should have shooed Steve away with "Do it yourself!
>>EDT macros are easy!"? Did I mention she was gorgeous? Anyway...
>
>
> You did, but you did not mention she was a woman. I thought I had just
> gotten a very personal insight into Kenny.
>
I guess the Lisp Directory AFJ wore off on me.
:)
kt
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
On 2006-04-05 01:42:57 -0400, Benjamin Teuber <······@web.de> said:
> Pascal Bourguignon wrote:
>
>> I see only data, and there is only data!
>
> No, data is an illision - in fact there is only code :)
"The wind is not moving, the flag is not moving. Mind is moving."
Benjamin Teuber wrote:
> Pascal Bourguignon wrote:
>
>> I see only data, and there is only data!
>
>
> No, data is an illision - in fact there is only code :)
Does self-evaluating data count as code? I, personally, don't think so.
If everything was lambdas, there would only be code.
--
The science of economics is the cleverest proof of free will yet
constructed.
I believe a nice and insightful search for an answer to "there is only
data, or there is only code?" can be found in the book:
Gödel, Escher, Bach, an Eternal Golden Braid
by Douglas Hofstadter
It in fact talks about data, but data which talks about itself, so it
makes a strange loop and suddenly stops being just numbers, but logic
statements and so on.
...unless I'm totally and utterly wrong, which I can be, because I'm
only halfway through the book.
Anyway, Escher drawings are cool.
Ken Tilton wrote:
> heh-heh, actually, they are a lot harder than regular code.
Not really. A macro is just a function called at compile time with
unevaluated (ie: source text) arguments. Its result is substituted into
the source code in place of the macro call, and the new code is compiled.
--
The science of economics is the cleverest proof of free will yet
constructed.
Eli Gottlieb <···········@gmail.com> writes:
> Ken Tilton wrote:
> > heh-heh, actually, they are a lot harder than regular code.
> Not really. A macro is just a function called at compile time with
> unevaluated (ie: source text) arguments.
Except this isn't really correct on two counts. The more egregious
one being "unevaluated arguments to macros == source text"
/Jon
--
'j' - a n t h o n y at romeo/charley/november com