Walter Bright wrote:
> 4) The more experience I have, the more it seems that the language that got a lot right is ... Lisp. But Lisp did one thing terribly, terribly wrong - the syntax. The Lisp experts who can get past that seem to be amazingly productive with Lisp. The rest of us will remain envious of what Lisp can do, but will never use it.
> 
> 5) Lisp gets things right, according to what I've read from heavy Lisp users, by being a language that can be modified on the fly to suit the task at hand, in other words, by having a customizable language one can achieve dramatic productivity gains.

I suspect: C was a great language because it doesn't try to keep you away from the machine. Lisp is great because it doesn't try to hide you from the compiler.

To quote Stepanov (the link that Bill Baxter just posted):

Alexander Stepanov Notes on Programming 10/3/2006

Since I am strongly convinced that the purpose of the programming language is to present an abstraction of an underlying hardware C++ is my only choice. Sadly enough, most language designers seem to be interested in preventing me from getting to the raw bits and provide a “better” machine than the one inside my computer. Even C++ is in danger of being “managed” into something completely different. (p7)

Sadly enough, C and C++ not only lack facilities for defining type functions but do not provide most useful type functions for extracting different type attributes that are trivially known to the compiler. It is impossible to find out how many members a type has; it is impossible to find the types of the members of a structure type; it is impossible to find out how many arguments a function takes or their types; it is impossible to know if a function is defined for a type; the list goes on and on. The language does its best to hide the things that the compiler discovers while processing a program.  (pp. 43-44)

Bill Baxter wrote:
> janderson wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> James Dennett wrote:
>>>> C++, of course, has std::for_each(e.begin(), e.end(), do_x);
>>>> in its library (though that's weaker than it could be because
>>>> of lack of support for convenient anonymous functions/lambdas).
>>>>
>>>> C++0x is very likely to have for(v: e).  It's implemented
>>>> in ConceptGCC already. Java already has essentially that,
>>>> as does C#.  This really doesn't set D apart (but at least
>>>> D isn't falling behind here).
>>>
>>> BTW, D might soon have simultaneous iteration that will blow away all conventional languages:
>>>
>>> foreach (i ; coll1) (j ; coll2)
>>> {
>>>   ... use i and j ...
>>> }
>>> continue foreach (i)
>>> {
>>>   ... coll2 finished; use i ...
>>> }
>>> continue foreach (j)
>>> {
>>>   ... coll1 finished; use j ...
>>> }
>>>
>>> Andrei
>>
>> Maybe its a bit to late here however this syntax seems very special case.  Can you explain why its necessary and how we would use it.  How would we do this currently (without meta programming)?
>>
> 
> Yeh, I don't get it either.  How would that help me implement merge() from merge sort for instance?

Merge bumps the iteration in both collections conditionally. The form above bumps the iteration in the two collections unconditionally, until one is finished; then it continues with the other until that is finished.

Say you need to compute the minimum and maximum element for each column in a file. The code (translated from Perl) looks something like this (simplified):

foreach (row ; rows) {
  for (int i = 0; i != cols; ++i) {
    if (mins[i] > row[i]) mins[i] = row[i];
    if (maxs[i] < row[i]) maxs[i] = row[i];
  }
}

What you'd rather do is to simultaneously iterate row, mins, and maxs:

foreach (row ; rows) {
  foreach (e ; row) (inout min ; mins) (inout max ; maxs) {
    if (min > e) min = e;
    if (max < e) max = e;
  }
}


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
>> Yeh, I don't get it either.  How would that help me implement merge() from merge sort for instance?
> 
> Merge bumps the iteration in both collections conditionally. The form above bumps the iteration in the two collections unconditionally, until one is finished; then it continues with the other until that is finished.

In other words, it doesn't :(.

Johan Granberg wrote:
> X Bunny 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
>>
> From my attempt to learn lisp some months ago i think that at least 4 and 9
> is true (please correct me if I'm wrong). A big part of that issue is that
> it looks like the different implementations does things slightly
> differently and that creates a fragmentation of the community and causes
> libraries to require specific implementations (I'm mainly talking of the C
> interface here as that is what I looked at). Regarding 9 if you know a good
> lisp tutorial please post a link. (especially how to build code and the
> quote special syntax)

I do admit (4) is largely debateable, compared to D and many other successful languages its no harder, but certainly yes your point that different implementations have different ways of doing it is true and it is not mandated by the ANSI standard for the language. However the CFFI library abstracts these differences annd supports many implementations.
Regarding (9) a well regarded book is called Practical Common Lisp ( the complete text is online at http://www.gigamonkeys.com/book/ ).

My reasons why I dont use Lisp as often as I would like are:
1) Deploying Lisp applications can be difficult; huge exes if you can get your implementation to produce a standalone image atall.
2) Dependance on third party C++ libraries - DirectShow BaseClasses sigh :-( C++ libraries arent even compatible between C++ compilers nevermind to Lisp!
3) Too general - no matter how good Lisp is at doing everything there are languages written for a specific task which are probably better than Lisp for it within a limited niche. So long as you dont exceed the niche theres no need for Lisp. Definately there could have been a Lisp system which blows it away, there probably isnt, if there is does using it outweight the other points.
4) No company support - the boss is scared if I die no-one will maintain it as Lisp programmers are fairly rare.
5) Not a team player - by being subject to the above points Lisp starts to get pretty outcast in your toolbox because you know whatever you write with it might also only be useable in projects which can avoid those points too.

Apart from (1) these are also reasons why I dont get to use D as often as I would like.

Bunny

Don Clugston wrote:
>
> I think that if basic uses of recursion could be replaced with iteration and compile-time variables (even if they were mutable only inside foreach), it would become readable to average joe.

I agree.

Frits van Bommel wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Bill Baxter wrote:
>>> Yeh, I don't get it either.  How would that help me implement merge() from merge sort for instance?
>>
>> Merge bumps the iteration in both collections conditionally. The form above bumps the iteration in the two collections unconditionally, until one is finished; then it continues with the other until that is finished.
> 
> In other words, it doesn't :(.

A need for loops iterating over multiple collections depending on arbitrary conditions will always be there. The point of extending foreach is to address the often-encountered case when you want to iterate over multiple collections simultaneously (e.g.: copy a collection to another), just like foreach itself is addressing the particular but frequent case of iterating one collection in a linear manner.

Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Frits van Bommel wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Bill Baxter wrote:
>>>> Yeh, I don't get it either.  How would that help me implement merge() from merge sort for instance?
>>>
>>> Merge bumps the iteration in both collections conditionally. The form above bumps the iteration in the two collections unconditionally, until one is finished; then it continues with the other until that is finished.
>>
>> In other words, it doesn't :(.
> 
> A need for loops iterating over multiple collections depending on arbitrary conditions will always be there. The point of extending foreach is to address the often-encountered case when you want to iterate over multiple collections simultaneously (e.g.: copy a collection to another), just like foreach itself is addressing the particular but frequent case of iterating one collection in a linear manner.

What about:

    foreach (i ; coll1) (j ; coll2)
    {
        if( true )
            continue i;
    }

ie. allow 'continue' to accept labels to specify which collection is iterated.  A 'continue' without labels would iterate both.


Sean

Sean Kelly wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Frits van Bommel wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>> Bill Baxter wrote:
>>>>> Yeh, I don't get it either.  How would that help me implement merge() from merge sort for instance?
>>>>
>>>> Merge bumps the iteration in both collections conditionally. The form above bumps the iteration in the two collections unconditionally, until one is finished; then it continues with the other until that is finished.
>>>
>>> In other words, it doesn't :(.
>>
>> A need for loops iterating over multiple collections depending on arbitrary conditions will always be there. The point of extending foreach is to address the often-encountered case when you want to iterate over multiple collections simultaneously (e.g.: copy a collection to another), just like foreach itself is addressing the particular but frequent case of iterating one collection in a linear manner.
> 
> What about:
> 
>     foreach (i ; coll1) (j ; coll2)
>     {
>         if( true )
>             continue i;
>     }
> 
> ie. allow 'continue' to accept labels to specify which collection is iterated.  A 'continue' without labels would iterate both.

I think that's a great idea, except that "continue to label" has the same syntax: http://digitalmars.com/d/statement.html#ContinueStatement

Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Sean Kelly wrote:
>> What about:
>>
>>     foreach (i ; coll1) (j ; coll2)
>>     {
>>         if( true )
>>             continue i;
>>     }
>>
>> ie. allow 'continue' to accept labels to specify which collection is iterated.  A 'continue' without labels would iterate both.
> 
> I think that's a great idea, except that "continue to label" has the same syntax: http://digitalmars.com/d/statement.html#ContinueStatement

Does that really matter? The compiler knows whether 'i' is a label or a loop variable (presumably it can't be both at the same time?) so it knows what to do. Note that the current "continue to label" wouldn't help here since there's only one statement for a "double" iteration. So the most natural way to specify which loop to continue would be to specify the variable.


By the way, would the new loop syntax allow more than two collections to be simultaneously iterated?
That would indicate the need for a "continue i, j" as well, to specify multiple variables.
On the other hand, with your proposed "continue foreach" clauses after the main loop that would also require an exponential number of those clauses for different sets of collections running out if you want to handle all cases...

X Bunny wrote:
> My reasons why I dont use Lisp as often as I would like are:
> 1) Deploying Lisp applications can be difficult; huge exes if you can get your implementation to produce a standalone image atall.
> 2) Dependance on third party C++ libraries - DirectShow BaseClasses sigh :-( C++ libraries arent even compatible between C++ compilers nevermind to Lisp!
> 3) Too general - no matter how good Lisp is at doing everything there are languages written for a specific task which are probably better than Lisp for it within a limited niche. So long as you dont exceed the niche theres no need for Lisp. Definately there could have been a Lisp system which blows it away, there probably isnt, if there is does using it outweight the other points.
> 4) No company support - the boss is scared if I die no-one will maintain it as Lisp programmers are fairly rare.
> 5) Not a team player - by being subject to the above points Lisp starts to get pretty outcast in your toolbox because you know whatever you write with it might also only be useable in projects which can avoid those points too.
> 
> Apart from (1) these are also reasons why I dont get to use D as often as I would like.

(4) is not as large a problem as it might seem. Unlike Lisp, D can be picked up very quickly by an experienced C++/Java programmer.