m...@capita.nildram.co.uk (Martin ) writes: > Hmmmmm, deep space probe, programmed in Lisp, self-modifying code, a few > cosmic rays to stir things up a bit, a few million years of evolution... I > think I feel a sci-fi story coming on...
Yeah, you get the Ferengi. Their spaceships (the "Marauders") look a bit like fat parenthesis.
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
Rahul Jain <ra...@owlnet.rice.edu> writes: > "Pierre R. Mai" wrote:
> > a) Make sure you get an editor/environment that really supports Lisp > > programming. This means it offers automatic indenting and paren > > blinking/highlighting, paren balancing commands and editing > > commands that work on s-exps. Add to that the ability to run a > > lisp listener in this environment and communicate with it, giving > > access to it's built-in information on argument-lists, doc-strings, > > etc. and automatic lookup of symbols in the HyperSpec (if you are > > using CL and not Scheme). In other words this probably means an > > Emacs (GNU Emacs or XEmacs) with ILISP or ELI and/or one of the > > IDEs that come with your CL implementation.
> If I have the time to set up a sane set of keybindings I > will... until then it's nedit for me... If anyone has a good smart > indent routine for nedit, I'd be much obliged.
[ Note: I assume, from a comment you made later in your post, that parentheses were your main keybinding problem. ]
You think *you* have a problem, having to press shift to get parentheses? What about people who use non-english keyboards, who have to press AltGr to get braces and brackets? (Actually, this is a good reason for switching to Lisp :-)
Also, in C/C++ (for example) the number of parentheses plus braces in a typical program is *much* higher than the number of parentheses in the equivalent Lisp program. (Proof left...)
> > b) You will start to see why in 40 years of Lisp, we have stuck with > > s-exps as the surface syntax. You will see that s-exps aren't > > nearly as unworkable as you once thought, and that they offer a > > number of very tangible advantages in shaping your thought > > processes, increasing orthogonality and easing macro development > > (and many other data-structure manipulation operations).
> No argument there, that's why I wanted the /option/ to do it. :) > But that question is already answered, and much to my satisfaction. The best > part is that it can give you the s-exp form of it without much work. > Thanks a billion, guys :) > Now to remap my parens so that I don't need to hit shift to use them ;)
You're not going to get the most out of Lisp if you start by camouflaging it as something else. I suggest that you take a look at Graham's books (particularly "On Lisp"); if that doesn't make you see the light about the s-exp form, nothing will.
Raymond Wiker <raym...@orion.no> writes: > Rahul Jain <ra...@owlnet.rice.edu> writes:
> > And one other thing... > > *puts on asbestos underwear* How about some strong typing so that > > stupid me can avoid silly mistakes like putting params in the > > wrong order or returning a struct instead of the symbol that names > > it... *smirk*
> Strong typing *doesn't* stop you from making errors in > parameter ordering. Next...
> On a more useful note: Lisp *has* facilities for checking > types of parameters, and also value ranges of individual > parameters. C/C++ has the latter in a very limited form, by way of > assert(); the Lisp "equivalent" gives you the option of modifying the > parameter(s) and continue the program.
And any sane Lisp environment can get, display and event insert the lambda list (i.e. the list which specifies which parameters in which order (if ordered) the function takes) to the function by the touch of a button (or 2). For example in Emacs with ILISP:
C-c a Return the arglist of the currently looked at function. With a numeric prefix, the arglist will be inserted. With a negative one, the symbol will be prompted for.
Another key-binding often used for this is C-M-a.
C-c d Return the documentation of the previous symbol. It uses 'ilisp-documentation-command'. If the symbol is at the start of a list, it is assumed to be a function, otherwise variable documentation is searched for. With a minus prefix, prompt for the symbol and type. With a numeric prefix always return the current function call documentation.
The above work for all functions, i.e. your own functions or the functions from the guy across the country, too.
If the function you are planning to call is part of ANSI CL, you can look it up in the HyperSpec, too. Using Erik Naggum's hyperspec.el, I've got
C-c h View the documentation on SYMBOL-NAME from the Common Lisp HyperSpec. If SYMBOL-NAME has more than one definition, all of them are displayed with your favorite browser in sequence. The browser should have a "back" function to view the separate definitions.
The Common Lisp HyperSpec is the full ANSI Standard Common Lisp, provided by Kent Pitman and the Harlequin Group. By default, the Harlequin WWW site is visited to retrieve the information. The Harlequin Group allows you to transfer the entire Common Lisp HyperSpec to your own site under certain conditions. Visit http://www.harlequin.com/books/HyperSpec/ for more information. If you copy the HyperSpec to another location, customize the variable `common-lisp-hyperspec-root' to point to that location.
Add to this that you should use keyword arguments for seldomly used parameters of functions (when defining them), like most functions in ANSI CL itself do:
(remove #\E "A simple demonstration sentence with a lot of E's." :test #'char-equal :start 23)
So IMHO the danger of mixing up parameters can be reduced to a very small epsilon, indeed. In fact, I can't remember when I last mixed up parameters in a function call...
Regs, Pierre.
-- Pierre Mai <p...@acm.org> PGP and GPG keys at your nearest Keyserver "One smaller motivation which, in part, stems from altruism is Microsoft- bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Marco Antoniotti wrote: > m...@capita.nildram.co.uk (Martin ) writes:
> > Hmmmmm, deep space probe, programmed in Lisp, self-modifying code, a few > > cosmic rays to stir things up a bit, a few million years of evolution... I > > think I feel a sci-fi story coming on...
> Yeah, you get the Ferengi. Their spaceships (the "Marauders") look a > bit like fat parenthesis.
What?? We're Ferengi? Ugh. Well, at least we get all the hot women.. [and the cash ;-> ]
Gareth McCaughan <Gareth.McCaug...@pobox.com> wrote: > > Why? What advantage does Python give you over > > Lisp?
> A different set of libraries, handier for some uses. > A usable and very portable GUI.
Could we just take the python GUI and use it from say clisp, acl, lcl, cmucl via a ffi? Would this work on Unix and Windows? Would this have advantages over using Tk?
Rahul Jain <ra...@owlnet.rice.edu> writes: > And one other thing... > *puts on asbestos underwear* > How about some strong typing so that stupid me can avoid silly mistakes like > putting params in the wrong order or returning a struct instead of the symbol > that names it... > *smirk*
CMU CL prints warnings or even deletes code that is no longer reachable when you get your declared types wrong.
Raymond Wiker wrote: > [ Note: I assume, from a comment you made later in your post, > that parentheses were your main keybinding problem. ]
That's the problem if I use nedit. In emacs, I'd want to change the bindings to be a bit more like I want them (that's just a matter of me sitting down and actually figuring out how to really use emacs and then configuring it)
> Also, in C/C++ (for example) the number of parentheses plus > braces in a typical program is *much* higher than the number of > parentheses in the equivalent Lisp program. (Proof left...)
I agree with that comment, but the parens are much more visible when there's 8 of them in a row ;)
> You're not going to get the most out of Lisp if you start by > camouflaging it as something else. I suggest that you take a look at > Graham's books (particularly "On Lisp"); if that doesn't make you see > the light about the s-exp form, nothing will.
I know the utility of the s-exp form, but it's a real pain to have to convert a mathematical equation to it. Maybe it's just because I'm only used to in- and postfix notation. Eventually I'll master prefix notation and be the master of all notation (except for any really strange ones that I've never head of....) :P
-- -> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <- -> "I never could get the hang of Thursdays." -Douglas N. Adams <- -> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <- -> -=-=-=-=-=- E-mail: mailto:rahul-j...@usa.net -=-=-=-=-=- <- Version 9.105.999.1111111111111.23.042 (c)1996-1998, All rights reserved. Disclaimer available upon request.
Rahul Jain <ra...@owlnet.rice.edu> writes: > Raymond Wiker wrote:
> > [ Note: I assume, from a comment you made later in your post, > > that parentheses were your main keybinding problem. ]
> That's the problem if I use nedit. In emacs, I'd want to change the bindings to > be a bit more like I want them (that's just a matter of me sitting down and > actually figuring out how to really use emacs and then configuring it)
No need to involve emacs at all - at least assuming that you're using XWindows (Note: untested, but "should" work on english (UK *and* US) keyboards):
> > Also, in C/C++ (for example) the number of parentheses plus > > braces in a typical program is *much* higher than the number of > > parentheses in the equivalent Lisp program. (Proof left...)
> I agree with that comment, but the parens are much more visible when there's 8 of > them in a row ;)
Ah, but *those* are the _invisible_ kind of parens :-)
> > You're not going to get the most out of Lisp if you start by > > camouflaging it as something else. I suggest that you take a look at > > Graham's books (particularly "On Lisp"); if that doesn't make you see > > the light about the s-exp form, nothing will.
> I know the utility of the s-exp form, but it's a real pain to have > to convert a mathematical equation to it. Maybe it's just because > I'm only used to in- and postfix notation. Eventually I'll master > prefix notation and be the master of all notation (except for any > really strange ones that I've never head of....) :P
That's a valid concern. On the other hand, if you have a strict representation of equations (for example, based on s-exps, but limited to unary and binary operations, plus n-ary functions), you can easily use this form to create a variety of more readable forms (e.g, TeX or PostScript output...)
Also, equations in s-exp form can *easily* be transformed - examples are simplification, normalisation, symbolic derivation etc.
>>> Why? What advantage does Python give you over >>> Lisp?
>> A different set of libraries, handier for some uses. >> A usable and very portable GUI.
> Could we just take the python GUI and use it from say clisp, acl, lcl, > cmucl via a ffi? Would this work on Unix and Windows? Would this have > advantages over using Tk?
The GUI *is* Tk. Python has a tolerable set of wrappers for it.
-- Gareth McCaughan Gareth.McCaug...@pobox.com sig under construction
* Rahul Jain | I know the utility of the s-exp form, but it's a real pain to have to | convert a mathematical equation to it. Maybe it's just because I'm only | used to in- and postfix notation. Eventually I'll master prefix notation | and be the master of all notation (except for any really strange ones | that I've never head of....) :P
(defun trivial-infix-reader (input-stream char) (declare (ignore char)) (let ((list (read-delimited-list #\] input-stream t))) (cond ((null (cddr list)) list) ;trivial: 1- and 2-lists ((null (cdddr list)) ;swap first and second of 3-lists (list (second list) (first list) (third list))) (t (list* (second list) (first list) (loop with operator = (second list) for pair on (cdr list) by #'cddr unless (cdr pair) do (error "infix expression is not well-formed") unless (eq operator (first pair)) do (error "infix operator is not properly redundant") collect (second pair)))))))
when this definition is available, you may evaluate
(set-macro-character #\[ 'trivial-infix-reader)
(set-syntax-from-char #\] #\))
and type things like [2 + 3], [sqrt pi], [10 log 2], [x < y < z], and have them all come out right.
for a more powerful infix reader that does precedence and such, there is some stuff available in the Common Lisp archives, but I suggest you stick to the above simplicity so you don't get dragged into maintaining a mini- language which nobody will benefit from, including yourself some ways down the road.
Rahul Jain <ra...@owlnet.rice.edu> writes: > And one other thing... > *puts on asbestos underwear* > How about some strong typing so that stupid me can avoid silly mistakes like > putting params in the wrong order or returning a struct instead of the symbol > that names it... > *smirk*
How about getting CMUCL, DECLAREing your parameters and compiling the code?
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
Over in the other thread, someone was trying to make a case for Lisp "power" or what-have-you. I think the relative ease (Erik's solution is 17 lines of code) with which one can make radical changes to the *language itself*, all on the fly no less, sets Lisp apart from e.g. C or Java or Python. There is *no* way to do something equivalent (e.g. switch to a prefix notation) in C without some serious hacking on the C compiler's parser. C's macro system is only a glorified search-and-replace, whereas Lisp's macro system (including reader macros) allows the user to truly transform the language.
(I point this out because it's probably possible to build continuations in C (with setjmp/longjmp). Not easy, like the LAMBDA and CALL/CC operators, but possible.)
-- "I try to take life one day at a time, but lately several days have attacked me at once." -- Carrie Fish
>>>>> "FDMM" == Fernando D Mato Mira <matom...@iname.com> writes:
FDMM> Actually, I found CS ladies to intuitively `get' Lisp FDMM> immediately. This might be telling something deep about the FDMM> `macho C coder' psychology..
Heh. I think it has a lot more to say about my pale complexion, sleep-deprived growl, and forgetfulness of personal hygiene. ;)
FDMM> Or is it a cash issue? :->
Nope. I'm a conslutant. Cash isn't too much of a problem.
-- "I try to take life one day at a time, but lately several days have attacked me at once." -- Carrie Fish
Gareth McCaughan <Gareth.McCaug...@pobox.com> wrote: > The GUI *is* Tk. Python has a tolerable set of wrappers > for it.
Well, the most popular of the cross platform Python GUIs is Tk. There are several others, most of which are actively maintained and evolving. There are also several platform specific ones. Dan Pierson, Control Technology Corporation d...@control.com
In article <38178DF4.5BB36...@owlnet.rice.edu>, Rahul Jain <ra...@owlnet.rice.edu> wrote:
>"Pierre R. Mai" wrote: >> a) Make sure you get an editor/environment that really supports Lisp >> programming. This means it offers automatic indenting and paren >> blinking/highlighting, paren balancing commands and editing >> commands that work on s-exps. Add to that the ability to run a >> lisp listener in this environment and communicate with it, giving >> access to it's built-in information on argument-lists, doc-strings, >> etc. and automatic lookup of symbols in the HyperSpec (if you are >> using CL and not Scheme). In other words this probably means an >> Emacs (GNU Emacs or XEmacs) with ILISP or ELI and/or one of the >> IDEs that come with your CL implementation.
>If I have the time to set up a sane set of keybindings I will... until then >it's nedit for me... >If anyone has a good smart indent routine for nedit, I'd be much obliged.
Gareth McCaughan <Gareth.McCaug...@pobox.com> wrote: > Dan L. Pierson wrote:
> >> The GUI *is* Tk. Python has a tolerable set of wrappers > >> for it.
> > Well, the most popular of the cross platform Python GUIs is Tk. > > There are several others, most of which are actively maintained > > and evolving.
> Quite true. The GUI to which I was referring, however, was Tk. :-) > (Does any of the others support all three of Unix, Windows and Mac?)
Hmmm, don't know for sure because I don't do any Mac development. - wxWindows claims that a Mac version is underway - OpenAmulet claims Mac support but doesn't appear to have downloadable binaries for it. Dan Pierson, Control Technology Corporation d...@control.com
> > [I've changed the subject line to something less inflammatory.]
> > Janos Blazi wrote:
> > > (1) > > > I completely understand that someone may prefer LISP to C++. But why should > > > I prefer LISP to PYTHON?
> A real GC? I believe the original C-based version of Python just has > reference-counting.
> __Jason
Interesting point, but working programmers don't choose their tools for the language features they can tick off. In practice, reliability and acceptable performance are what count. Python's reference counting doesn't seem to cause many problems to its users.
I think the advantages of Lisp over Python are obvious - execution speed, abstraction. But although I prefer Lisp to Python as a language, but the libraries I can access while using Lisp are comparatively impoverished. There are advantages to using a language exactly because it's widely used. The "widely used" thing happened to Python because it's free to acquire, and easy to learn. Compare that to Lisp, which scares a lot of programmers - probably wrongly - and which doesn't have seem to have an acceptable free implementation that's available for all the major platforms. The lack of a Windows CMUCL make's me wince.
Of course, this is understandable. Decent Lisp compilers are obviously *much* harder to engineer than Python or C++ tools. Dynamic typing plus speed - ouch!
> > A real GC? I believe the original C-based version of Python just has > > reference-counting.
> Interesting point, but working programmers don't choose their tools for the > language features they can tick off. In practice, reliability and acceptable > performance are what count. Python's reference counting doesn't seem to > cause many problems to its users.
Posters in the Python newsgroup report having to workaround this limitation by avoiding cycles or snipping them before dropping all external references. In practice Python programs are probably shorter scripts and either don't build such complicated data structures or don't care so much about leakage as they do their job quickly and then terminate.
> I think the advantages of Lisp over Python are obvious - execution speed, > abstraction.
I would hope that's not all, but perhaps "abstraction" covers a multitude of virtues.
> But although > I prefer Lisp to Python as a language, but the libraries I can access while > using Lisp are comparatively impoverished.
Well most Lisps can invoke existing C APIs which is how many OS services are exported. Moreover some Lisps can load them dynamically without having to pre-link them into the Lisp executable. E.g. you can sit in a Lisp listener pick a library, load it, describe the function you want to call, and call it.
Perhaps what you meant was that there are fewer standardized Common Lisp wrappers that hide the grotty details of existing C libraries?
