Re: Very poor Lisp performance

Jon Harrop wrote:
> Rob Thorpe wrote:
> > Firstly, at the language level, since everything - data and code - is
> > represented as above the language becomes more amenable to automatic
> > operations.
>
> Yes. But is that related to the grammar?

It could be done with a different grammar, yes, though it may be
slightly more difficult. But it's very obvious when done with the
grammar of lisp, because a human can predict the behaviour of the
automatic operations mentally.

> > Some examples:-
> >
> > 1. If I load my buggy version of your raytracer into lisp and do:
> >
> > (setq foo (ray-sphere ray sph))
> >
> > foo now contains a huge tree. Should I want this tree in the future
> > (for more debugging f.e.g) I can print it to a file with print, then
> > later read it back with read.
>
> That's cool. I guess the nearest in OCaml is to use the compiler's lexer and
> parser to input the code and then marshall it to disc. Not very elegant...

It's quite useful, it can eliminate the need for data-file
parsers/lexers sometimes.

> > 2. Emacs does not have to guess things about lisp. With other
> > languages it occasionally has to guess, because it cannot understand
> > the syntax in reasonable time. When it tells you all the parens match,
> > they match.
>
> Ok. Can you give an example of a time when emacs has to guess?

Things like s%regex%regex% in Perl are one example, lots of syntax
highlighters get them wrong. In general any situation where the syntax
of the language masks or buries parens or brackets. Syntax recognition
programs make all kinds of hidden assumptions about code, such as
assuming that the indentation is locally correct when adding more.

> > 3. In a place (a fearful place :) ) that doesn't have emacs all is not
> > lost. If lisp can read the code it can print it. So, I can quote the
> > list with a quote mark*, and watch it:
> >
> > '((defun fib (x) (if (<= x 2) 1 (+ (fib (- x 2))(fib (1- x)))))
> >
> > It will then spit it back with whatever default formatting the lisp
> > printer uses for lists (there may also be an option for printing
> > functions in the printer). The formatting may not be very nice, but if
> > the code is truely hairy it will be more understandable than it was.
> > You can use this sort of this to do things like substituting sub-trees
> > in your code.
>
> Right, I saw that in Sussman's lecture (IIRC).
>
> > (* quote marks are one of the few true bits of syntax)
>
> Yes, "#" and ";" seem to be others. I don't know what "#" does.

The most common syntax is:
"." - pair
"'" - quote
"#'" - function call
"#" - make simple-vector
"#S" - structure

There are several more not often used. These are all reader-macros.
I describe "read" as though it is simple, because for most purposes of
understand it is. But underneath it's rather complicated, see
http://www.lisp.org/HyperSpec/Body/sec_2-2.html if you're interested.
Complex reader macro aren't that commonly used thankfully.

> > 4. It makes macros easier to understand since they act on trees.
>
> So you predict that Lisp macros are easier to understand than OCaml's
> macros?

No, I wasn't predicting anything.
I was just say that it's easy to understand what is does because the
text is a tree itself. I'll have a look at ML macros.

> > All of the above describes benefits in automatic formatting, not
> > readability.
> > Some people find it readable, some don't. I personally don't find it
> > very easy or very difficult. There are a number of tricks to reading
> > it and writing it.
>
> I'm finding prefix notation readable but overly verbose. Counting
> parentheses is a real pain though. Assuming the Lisp advocates here also
> know conventional languages then there is plenty of evidence that one can
> learn to read Lisp.

Lots of indentation is needed, that's most of what makes it more
verbose.
Also, in Common lisp, the fact that the function names are so long.

> > The easiest way to find out is to delete all the closing parens at the
> > end with Emacs. You then replace them one by one, the cursor will
> > highlight the opening paren as this happens. You can then watch them
> > and check they go in the right places. Once you've finished closing
> > the parens on the line you're on, the rest should match on the lines
> > above to each left-most paren.
>
> Yes. That is almost exactly what I am doing.

As far as I know that's the main trick to it, that and knowing how many
parens certain constructs start with, for example
(let ((<- two parens
(defun (<- one paren
(labels ((<- two parens

There are probably other tricks old lispers know.

> > It also means errors can't leak syntactically: the error is in one
> > form. They can certainly leak semantically though.
>
> Yes. I think that the majority of the errors I get in other languages are
> already semantic though.

Me too, it doesn't gain you much.

.

Relevant Pages

  • Re: How Lisps Nested Notation Limits The Languages Utility
    ... «Some 99% of programers are not used to the nested parenthesis ... syntax can be considered a problem.» ... Why else has Lisp recovered from the AI Winter? ... Nowhere did I say people would have to struggle to appreciate parens, what I said was that it is not interesting if people who have never tried Lisp complain about the parens. ...
    (comp.lang.lisp)
  • Re: Very poor Lisp performance
    ... Emacs does not have to guess things about lisp. ... When it tells you all the parens match, ... > readability. ... know conventional languages then there is plenty of evidence that one can ...
    (comp.lang.lisp)
  • Re: Verbose functional languages?
    ... I just don't like the syntax. ... I'm not a big fan of Lisp, ... ML-style languages. ... So common practise matters. ...
    (comp.lang.functional)
  • Re: Planning to learn C/a new language, your suggestions please
    ... You use this statement somewhat inconsistently by trying to bash Haskell ... Ada's syntax is 'larger', but it isn't so ugly its size becomes bothersome. ... On most systems doing most tasks, the performance of interpreted languages ... Lisp has the simplest syntax that's actually usable by human beings. ...
    (comp.lang.c)
  • Re: Where does the drive to syntax come from?
    ... > non-programmers have an idea what languages should look like and it's ... > thus all the different bits of syntax in Perl. ... (Certainly within Lisp ... > macros, diffferent syntax for different kinds of numbers, LOOP, ...
    (comp.lang.lisp)