Super-dee-duper D features

[X Bunny]

Kevin Bealer wrote:
>> My personal feelings as to why Lisp isnt as popular as it could be are 
>> some of these misconceptions:
>>
>> 1) Its all functional code and recursion
>> 2) The syntax is weird and mindbending
>> 3) Lisp is interpreted and therefore slow.
>> 4) Its hard to interface Lisp with non Lisp libraries and operating 
>> system services.
>> 5) Lisp is old and hasnt changed since the 50's
>> 6) The features are really clever but they wouldnt be useful in a 
>> 'real' program
>> 7) Its for AI or 'weird' programs
>> 8) You have to be really clever to program in Lisp
>> 9) Lisp is poorly documented and hard for a beginner to understand
>> 10) Its irrelevant because we have Java/C++/something else now
> 
> I've looked at LISP a number of times but something always pushes me 
> away, including some of the misconceptions here, however:
> 

> 
> 2. The syntax doesn't provide visual hints that let you read a program.
> 
> Web pages use different colors, road signs use different shapes, other 
> languages use different punctuation, etc.  I can accept that they all 
> turn into trees on some level, but it makes it unreadable to represent 
> that in the syntax.  It's like writing all strings in hex notation. Yes, 
> yes, I know they turn into numbers.  Show me the strings anyway; and use 
> quotes when you do it.

I kinda follow you in the first part of this, that different punctuation 
makes it obvious that something important is happening at that point, ie:

(defun foo (x y)
   (+ x y))

is not syntactically different from:

(deffoo frob (x y)
   (+ x y))

and so you might miss the point that the first expression is probably 
defining a function. Syntax highlighting in the editor is a simple 
solution to that though. Really its no different than in another 
langauge, when you see:

Mixin!(Frob) Nuts;

Has any of the syntax made this more obvious about what it actually 
does? You know its a Mixin but so what, its not the punctuation which 
matters its the actually 'stuff' the symbols.

Lisp can be extended with extra punctuation though without having to 
rewrite Lisp if you think it helps. This is valid syntax which looks 
nothing like Lisp if you use the infix package:

#I(if x<y<=z then f(x)=x^^2+y^^2 else f(x)=x^^2-y^^2)

Its also worth noting though that in Lisp the deffoo expression may or 
maynot define a function also (depending on whatever deffoo does). This 
is an important part of the language though, Im not sure how atall in D 
you could make a macro which defined and generated based on some code as 
input, a new function.

Regarding the second part, its worth considering at what point do you 
consider syntactic sugar useful and why is it part of the language? 
certainly inputting a string as a list of hex values would be 
impractical but running with that if you did have a Lisp which only 
internally supported strings as a list of numbers it wouldnt matter 
since you could make a " macro character which generated the list for 
you. Its even argueably more useful than a system which only understands 
strings because it is hardcoded to generate a list of bytes when it sees 
text enclosed in quotes.

> 
> Accountants use paper with green bars on every other line, so that your 
> eye can *follow* it.  The green bars don't do anything else, but they 
> still help a lot with readability -- I've actually thought that other 
> books, i.e. novels might benefit from being printed this way.  Good 
> syntax needs to consider *ergonomic* concerns, not teach an important 
> lesson about parse trees.

I think theres even an Emacs mode which as you nest statements colours 
the matching parantheses a different colour. As for green bars, just my 
opinion but if you have a function with so many statements that it needs 
green bars to delimit them then its probably too big. With Lisp or D I 
can break the code up and probably would. (and use comments too!)

> 
> Most importantly: If a chair hurts everyone that sits in it, but "only 
> for the first year" its not a good chair.

Its there a reason to sit on the chair that makes the initial discomfort 
seem worthwhile? Is there a more comfortable alternative chair which 
does everything the chair does? Is it painful because you have bad 
posture from sitting too long on a beanbag? :-)

> 
> 3. I'm not sure I buy that this is a myth per se.

If you mean its true and therefore not a myth then you are wrong.
Almost all Common Lisp systems are compilers, most generate native code, 
some dont include an interpreter at all and compile interactively if you 
are programming interactively. Another misconception is that Lisp doesnt 
support typed variables and therefore is unable to generate fast but 
specific code like C or something else, again simply not true.

> 
> The rest I'll grant as probably misconceptions, especially 6.
> 
> I think the real clincher is that when people describe these kinds of 
> issues the LISP community's response seems to be something like "get 
> used to it and you won't notice it".  Other languages may catch up with 
> some of LISP's features, but what I consider to be the problems with 
> LISP can't be fixed because they aren't seen as problems.

I reckon there probably is a future possibility for a language which 
encompasses Lisps features but which is not Lisp. To be honest I dont 
really see it, since Lisp can already be extended to support additional 
syntax, those people who need to can implement it anyways and it would 
still be Lisp. Its worth noting that s-expressions (the Lisp syntax 
everyone but Lisp programmers has a problem with) wasnt the end-all of 
Lisp syntax there were also m-expressions which were supposed to be more 
human readable and an original goal of the development, programmers 
genuinely prefered sexp.


I think a nifty thing would be a D parser written in Lisp, the D parser 
would emit Lisp forms which would then be compiled like anyother Lisp 
code, additionally it could then interact with the rest of Lisp and if 
people felt the desire to write more off the wall stuff they could, D 
would remain what it is, extensions could be as D like as they wished. 
Probably the parser could be simpler than the complete D spec since 
probably the template stuff would be replaced by macros. Who knows?

Bunny