Until now i programmed in basic - pascal - visual basic - c - c++ - python , i looked at forth, haskell common-lisp , c#, f# , dylan ...... frustrated i was thinking about an own language and how it should be
( chromatic wrote an article , which has a lot of ideas i like, even if it might be an april-fool - http://www.oreillynet.com/onlamp/blog/2006/03/the_worlds_most_maintainable_p.html )
Paul Grahams Hackers&Painter book esp. his idea of the 100year-language is not bad - but he didn't realize that newLisp has already a lot of what he's dreaming of . ( ok , i can not follow his macro-hype , i must still think about that ... )
After i found newLisp i realized, that i could stop searching - it's already there , my language ! I like newLISP it's absolut super , it's modern, powerful - and the small footprint is amazing.
Because i have the idea to use newLISP in two ways for quite new applications and for everyday-programming ,therefore i have some questions and i'm happy to join this forum .
Hi there! We like newLISP too. Although I hear that it isn't everyone's 'cup of tea'... ;-)
I will try and help you, but I'm sure that very soon you will be asking questions to which I don't know the answers...
Didi,
Welcome. Glad to have you. Allow me to pipe in on the subject of macros.
The beauty of macros is that they allow you to create your own syntax for the language. This means that if the language does not support the feature you want, you can always implement it yourself using a macro.
For example, I came to lisp from PHP. After using the prototype JS library and seeing how useful lambda functions are (anonymous functions that can be passed as parameters to another function), I tried to find something similar in PHP. PHP's lambda is a joke (and not even subject to garbage collection, so using it to iterate over a list/array would create a memory leak), as PHP does not consider functions to be objects.
If PHP had macros, I could have written a macro that accepted a function definition as its argument (but then, I would never have found lisp or newlisp).
In fact, I replicated Ruby's each syntax in newLisp a little while back as an exercise to help teach myself macros. The difference between functions and macros is that macros do not evaluate their arguments as they are passed.
Normally, a function only has access to the values that result from the evaluation of its arguments. With macros, the function must evaluate those arguments itself. This gives it the opportunity to pass those code blocks to other functions or macros, evaluate only portions of them, alter their syntax, etc.
You could convert a statement like:
(my-macro write "hello world" 5 times)
And my-macro could convert that syntax to something like:
(dotimes (x 5)
(println "hello world"))
...or similar.
By the way, I am a bit overwhelmed of the positive reaction to my threads.
Like newLISP itself , this community here is really amazing.
@jeff
many thanks to your detailed explanation :-)
As you know both , do you think common lisp has more powerful macro possibilities than newLISP ?
Macros work almost identically between common lisp and newlisp. The main difference is that since newlisp is entirely interpreted, macros are expanded (processed by the interpreter) at runtime. In common lisp, macros have an advantage in speed over regular functions. The only other difference is syntactic - newlisp breaks from common lisp by using define and define-macro.
However, macros' are defined by the fact that their arguments are passed unexpanded, which is their major advantage. This is the same in all lisps (that I know of).
I heard a talk , a podcast on ITC from Matz the developer of ruby , he made a joke about Lisp , he said ' the answer to every problem for a lisp-programmer is A MACRO ' .
BUT thats no blame, i think now, if the core language has not the feature you need , you can program it yourself - if the language has THIS feature of expanding ..
Wouldn't it be good to have a collection of macros ?
Yes, and I do. Enjoy:
(set 'iter (trim (string iter) "|"))
(dolist (obj (eval object))
(eval (set (sym (eval iter)) obj))
(catch (doargs (a)
(if (= a 'end) (throw nil) (eval a))))))
...and run it:
(println item)
end)
Quote from: "cormullion"
He, he, he. :-) --Ricky
Now some weeks and a few hacks later i am sure , the first feeling i had is absolutely correct .
But what about macros - hmm .. lately i had the first ideas for macros , the new gui-server for example a new command ( gs:set-color L1 col1 L2 col2 L3 col3 ) or even better ( gs:set-color L1 to L 3 , col1 to col3 ) ... ok, not really something you need for living .
But ist it correct what Paul stated between the lines : " the smarter the program the more macros " ??
I can't believe that, for me today it seems like this : " the more macros , the bader the language "
newLISP has a huge instruction repertoire , about 300 commands in it's small exe file of about 200kbyte == 0.2 MB !! batteries included ;-)
OK - and if now and then one command is really missing , you can write it by your own with a macro !
.. but Lutz will be faster in the most cases ! :-)
PS : in short time there will be a gui-included version with about 1MB !
.. this is the size of 1/3 of an mp3-song !
PPS : I'm an amateur and i have not the insight of the big gurus - and who knows i might be a bit dumb .
Live and let live ... let's hack ..
Quote
Paul G. is talking about Common LISP. The style of programming in Common LISP is very different and it is also a compiled language while newLISP is a scripting (interpreted) language.
newLISP has macros too but they work a bit different, see point (10) here:
http://newlisp.org/index.cgi?page=Differences_to_Other_LISPs
to understand newLISP macros you should also get familiar with the following functions: expand, letex, doargs
Lutz
I think you only need macros when you don't want a function to evaluate its arguments immediately. I think of it like this:
(println "the answer to " e " is " (eval e)))
(calc (+ 2 2))
;-> the answer to 4 is 4
(define-macro (calc e)
(println "the answer to " e " is " (eval e)))
(calc (+ 2 2))
;-> the answer to (+ 2 2) is 4
The function is no good, because it only sees the '4', not the expression. The macro is better, because e was evaluated only when we wanted it evaluated, giving us a chance to see it unevaluated.
The idea behind macros is to be able to expand the syntax of the language itself when necessary. Granted, s-expressions make this both possible and less necessary, since you can pass a lambda as a "code block" to a function.
Here is a link to an article I wrote that (hopefully) explains a bit about macros and their use:
http://artfulcode.nfshost.com/files/macros.html
The beauty of macros is that they allow you to create syntactic structures specific to a program, often called domain-specific languages. For example, if you have a bunch of data stored in xml, you could convert it to a lisp list using the xml functions built into newLisp, and then name a macro after the document root element, allowing you to then "execute" that entire xml list structure as a program, as suggested in this article:
http://www.defmacro.org/ramblings/lisp.html
Thankyou very much for your help. I'll read these articles .
Until now i had no speed problem with newLISP , maybe with larger applications, i think an interpreter is fast enough for a lot of applications.
I wonder if there are applications i'm not able to program in newLISP , which need Common Lisp .
Quote
For heavy number/data crunching the compiled languages have still an advantage. But then you can import a lib for such jobs.
See base64 encoding discussion here:
http://www.alh.net/newlisp/phpbb/viewtopic.php?t=203&postdays=0&postorder=asc&highlight=mime&start=25
Quote from: "HPW"
Good point H-P!
Although it is more of a monolith, this is also the basic idea behind Emacs: the heavy-duty ops are primitives written in C, and accessible by Emacs Lisp, and all the rest is written in Emacs Lisp -- a great design idea which was way ahead of its time (at least in "software engineering" circles).
It's generally accepted that using macros to optimize a program is bad practice anyway. Macros should be used to implement functionality that is either not otherwise available for the lisp implementation or that otherwise would require duplication of logic.
OK ! - Macros are a universal tool to emphasize the language :-)
. . . .
Jeff mentioned this article : http://www.defmacro.org/ramblings/lisp.html Are there some similarities between 'Ant' as an interface to Java and the gui-server-interface ?
. . . .
I just wanted to write about some dark aspects of CL i've read today, then i found that it was already discussed here in the newLISP-Fan-Forum :
http://www.alh.net/newlisp/phpbb/viewtopic.php?p=380&highlight=gabriel#380
The topic was 'A Critique of Common Lisp" : http://www.dreamsongs.com/Files/clcrit.pdf
Gabriel compared COMMON LISP to a overweight beast , in this sense newLISP seems to me like a "lithe and lissom weasel" and for me newLISP's slogan could be
PS :
I do not feel the need to justify myself , why i use newLISP. The joy of programming with newLISP is enough .
Thanks didi for breaking the weekend ice! (I thought we were going to go the weekend without a post. He, he, he.)
Amen, to what Lutz said in that post, answering Joe Marshall.
To me, one of the worst, if not the worst, problems with CL is
Compare, in general, c.l.l. with this very discussion group. The difference is akin to that of night and day -- people here are very friendly and helpful (as well as being generally knowledgeable).
Now note that I said
Some weeks ago I had the idea that Lisp users are more than usually self-reflective and "meta-critical" because their chosen language encourages them to do that anyway...
I then had another coffee, and had the better idea that Lisp was quite complicated and so the clever people that use it are sometimes wont to get impatient with the less clever.
Then I stopped thinking about people I didn't know and started working with people I do know... :-)
... still haven't installed that Java stuff. Hopefully next week... :-)
Quote
When visually parsing a lisp list, evaluate from the inside out. After learning to do this, lisp's syntax will become so much easier to visualize than imperative programming, because with lisp you are, basically, writing the actual internal structure of the program, rather than a more declarative syntax that would get parsed and turned into something resembling the lisp structure.
When writing a lisp program, write from the bottom-up. It's all about abstraction. First, you write the most primitive elements your program will need. Then, you write other functions that will use those functions in order to abstract the more low-level stuff. In the end, you write a much smaller set of functions/macros that will be the api to the program. These have convenient syntax and build on the lower level elements of the program.
Sounds a bit like Forth methodology: design top-down; develop bottom-up. I never gave Forth a fair chance though. However, I'm finding newlisp more intuitive and way simpler to learn. Thanks!
This is a quote of the 'REPL behavior' thread, but i think it fits better in this thread.
What initially attracted me was the small size and the speed of Forth , especially when you work on small embedded systems - but you build your own world , it's very hard to understand a program for those who didn't write the program - and it's difficult to understand your own program after a while.
My impression is , that newLISP is made for 'real live' for practitioners.
You have nearly the same freedom as in Forth , you can do functional programming like in Haskell , you can do nearly everything what you can do with Common Lisp, BUT with newLISP you stay with both feet in this world - you have all possibilities for modern applications - and it's not too difficult to understand.
For me newLISP is quite the right mixture of small size, big power, modernity and understandability :-)
PS: it's cool feeling , when your realize that you wrote some pages of code without using "for-loops"
PPS : regarding to the quote , thats the reason why you use less variables, too.