Whats the best language to learn...

On 21 Aug., 00:07, stan <smo...@exis.net> wrote:
> Pascal J. Bourguignon wrote:
> > So if you want, or if you have a need to implement MS-Windows drivers
> > in lisp, there's nothing preventing you *doing so. *If you have a lot
> > of variations in the hardware you want to driver, it might even be
> > worthwhile economically to use lisp, since it would allow you to
> > generate the different drivers from *high level descriptions of the
> > hardware.
>
> You seem to have jumped the logic train here. You claim there is a CL
> implementation that runs directly on ix86 hardware and then leap to the
> claim the you can produce a windows driver. If you honestly don't see
> the problem with that reasoning, I'm afraid you aren't really up to
> being a lisp evangelist. Typically the lispers I know are comfortable
> with logic and would spot this problem with little effort.
>
> To be precise, are you claiming that lisp is the best practical choice
> for developing Vista drivers? Can you point me to even one working
> vista driver written in lisp?
Mayby this explains the problems with vista drivers I have heard of.

> >> I think you get my
> >> point. I'm not implying lisp doesn't have good points; only that it's
> >> not "absolutely" superior to every other language ever invented for
> >> every application ever concieved. Every tool has limits; lisp is not
> >> universal.
>
> > Ok, lisp won't help you to put on your socks, (well until there is
> > some robot programmed in lisp able to do that).
>
> > But lisp is a universal programming language.
>
> Theoritically, at least. There are people who claim that Elvis is still
> alive and that the moon landing was faked. Now we have the equally
> unsubstantiated claim that lisp is universal and superior. Did Elvis
> tell you this while the two of you walked on the moon landing stage?
:-)
You just found out the information source of the Lisp fanatics.

Interestingly the people who criticize the Seed7 programming
language, with the most agressive arguments, were always Lisp
people.

Either they claim that some feature of Seed7 is already present for
ages in Lisp or they say that such a feature is just stupid because
it is not present in Lisp.

Several of my FAQ answers were improved a lot just to counter
some arguments of Lisp fanatics.

Lisp fans just don't get it that compile-time type checking has
advantages. This motivated me to write the following FAQ answers:
http://seed7.sourceforge.net/faq.htm..._type_checking
http://seed7.sourceforge.net/faq.htm..._type_checking

Other Lisp fans think that the syntax of a function call is the same
as the syntax of an operator call. Lisp fans have argued that Lisp
has overloadable user definable operators with priority and
assoziativity and their solution would require to write a whole
parser with read macros. Even if overloading, priority and
assoziativity could be managed, compile-time type checking
would still be missing. And: If you have to write a whole parser
with read macros macros this would be a new language and
not Lisp. This inspired me to write the following FAQ answer:
http://seed7.sourceforge.net/faq.htm#lisp_comparison

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Jean-Claude Arbaut wrote:
> Juha Nieminen wrote:
>> cr88192 wrote:
>>>> (Besides, what's your fixation with this "coctail sort". Insertion
>>>> sort is the most efficient way of speeding up quicksort.)
>>> actually, heapsort is the best way of speeding up quicksort, but it
>>> is complicated.
>>
>> No, it isn't. Sorting a partition of less than about 20 elements with
>> heapsort is a LOT slower than sorting it with insertion sort.
>
> And ? What about 200 elements ? 2000 ? More ?

The question was about speeding up quicksort. What I meant with this
is the classical "stop partitioning partitions smaller than n, and
instead sort them with a fast O(n^2) algorithm".

> For 20 elements a bubble sort will be perfect, btw.

No, it won't. Bubble sort is probably the worst possible choice to
sort such a small array.
Insertion sort is one of the best possible O(n^2) algorithm for that
situation.

Not convinced? Let's assume we have an array of 20 elements which is
otherwise already sorted, except that the last element is the smallest
one. How many operations will insertion sort perform?

First insertion sort will traverse the array from the beginning to the
end, each time making a comparison between pairs of elements. That makes
20-2=18 comparisons (not counting the last pair comparison, which is
counted next). Then it finds the smallest element and starts moving it
towards the beginning (by moving all the elements one step towards the
end). This requires 20-1=19 comparisons and 20+1=21 element assignments
(first we assign that last element to a temporary, after which we move
all elements one step towards the end, thus a total of 19 assignments,
and then we assign the temporary to the first element). Then the
algorithm ends, because it has reached the end of the array.

Thus a total of 37 comparisons and 21 assignments.

Now bubble sort: The first pass performs 20-1=19 comparisons and one
swap (ie. three assignments). The next pass performs 19-1=18 comparisons
and one swap. The next one 18-1=17 comparisons and one swap. And so on.
The total number of such passes will be 19, and thus the total number of
comparisons will be 19+18+17+...+1 = 190. The number of swaps will be
the same as the number of passes (because at each pass one swap is
performed), ie. 19. Because a swap consists of three assignments, that
makes a total of 57 assignments.

Thus bubble sort performs 190 comparisons and 57 assignments.

Compare that to the 37 comparisons and 21 assignments of insertion sort.

Bubble sort is "perfect"? Bullshit.

As far as I can tell, there exist no cases where bubble sort would be
more efficient than insertion sort. At most it could be equally
efficient, and even those cases are extremely rare.

Why does this matter? Because when you are using this kind of O(n^2)
algorithm to speed up quicksort, you need to potentially run it
hundreds, if not thousands of times for all those small partitions, and
any additional comparison/assignment counts with respect to speed.

thomas.mertes@gmx.at writes:
> Lisp fans just don't get it that compile-time type checking has
> advantages.

Why did they implement compile-time type checking in open source
compilers such as sbcl then?


> Other Lisp fans think that the syntax of a function call is the same
> as the syntax of an operator call.

In lisp it is the case, and it is a discriminant advantage for what
lisp wants to do.

> Lisp fans have argued that Lisp has overloadable user definable
> operators with priority and assoziativity and their solution would
> require to write a whole parser with read macros.

You are inconsistent. If you make extravagant demands on lisp, we
have the tools and hooks needed to implement them. If you make honest
demands on lisp, we have easy and well integrated solutions.


> Even if overloading, priority and assoziativity could be managed,
> compile-time type checking would still be missing.

Compile time type checking is orthogonal. I don't see the beginning
of an argument.


> And: If you have to write a whole parser
> with read macros macros this would be a new language and
> not Lisp.

This is the point of lisp. What do you thing the expression
"meta-programming" means?

--
__Pascal Bourguignon__

On 27 Aug., 15:49, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> thomas.mer...@gmx.at writes:
> > Lisp fans just don't get it that compile-time type checking has
> > advantages.
>
> Why did they implement compile-time type checking in open source
> compilers such as sbcl then?

Is the compile-time type checking mandatory or optional?
Is it necessary to define all variables/parameters with a type
specification?
Do the type checks also include function results?

> > Other Lisp fans think that the syntax of a function call is the same
> > as the syntax of an operator call.
>
> In lisp it is the case, and it is a discriminant advantage for what
> lisp wants to do.

The normal understanding of operators (at least for some
mathematical ones) is that they are infix and have a priority
and an associativity. This is not the case with Lisp function
calls. Logically operator and function calls are the same but
not syntactically.

> > Lisp fans have argued that Lisp has overloadable user definable
> > operators with priority and assoziativity and their solution would
> > require to write a whole parser with read macros.
>
> You are inconsistent. * If you make extravagant demands on lisp, we
> have the tools and hooks needed to implement them. *If you make honest
> demands on lisp, we have easy and well integrated solutions.

I do not make any demands on Lisp. This is just what some lisp
fan told me how overloadable user definable infix operators with
priority and assoziativity could be implemented in Lisp. But this
is nothing special: A parser that translates from one representation
(infix operator syntax with priority and associativity) to another
(lists) can be written in any language.

For Seed7 overloadable user definable infix operators with priority
and assoziativity are not an extravagant demand. Naturally this
is supported by Seed7. No need to write a parser.

Now you can choose between:
- This is a stupid feature
- Lisp has it also built in

> > Even if overloading, priority and assoziativity could be managed,
> > compile-time type checking would still be missing.
>
> Compile time type checking is orthogonal. *I don't see the beginning
> of an argument.

The argument is that writing a parser with read macros is not
enough because mandatory compile-time type checking
(although orthogonal) would still be an open issue.

BTW.: Types and overloading are related.

> > And: If you have to write a whole parser
> > with read macros macros this would be a new language and
> > not Lisp.
>
> This is the point of lisp. *What do you thing the expression
> "meta-programming" means?

Syntax and semantic are two different things.
Being able to support the semantic of new language constructs
is not the same as being able to support the syntax of new
language constructs. While Lisp can support many language
constructs with new invented semantics it is necessary to write
a parser to support a new syntax.

Seed7 supports constructs with new syntax and new semantic.
It is not necessary to write a parser to support a new
syntactic construct.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Juha Nieminen wrote:
> Jean-Claude Arbaut wrote:
>> Juha Nieminen wrote:
>>> cr88192 wrote:
>>>>> (Besides, what's your fixation with this "coctail sort". Insertion
>>>>> sort is the most efficient way of speeding up quicksort.)
>>>> actually, heapsort is the best way of speeding up quicksort, but it
>>>> is complicated.
>>> No, it isn't. Sorting a partition of less than about 20 elements with
>>> heapsort is a LOT slower than sorting it with insertion sort.
>> And ? What about 200 elements ? 2000 ? More ?
>
> The question was about speeding up quicksort. What I meant with this
> is the classical "stop partitioning partitions smaller than n, and
> instead sort them with a fast O(n^2) algorithm".

Oh, ok, sorry.

>> For 20 elements a bubble sort will be perfect, btw.
>
> No, it won't. Bubble sort is probably the worst possible choice to
> sort such a small array.

Actually I had not the accelerated quicksort in mind. If you really
have 20 elements to sort, bubblesort will do the job. Not the
fastest, but still enough.

> Insertion sort is one of the best possible O(n^2) algorithm for that
> situation.

Bubble sort is O(n^2)

> Not convinced? Let's assume we have an array of 20 elements which is
> otherwise already sorted, except that the last element is the smallest
> one. How many operations will insertion sort perform?


> Bubble sort is "perfect"? Bullshit.

Perfectly enough I meant. Bad english, not bad idea

> As far as I can tell, there exist no cases where bubble sort would be
> more efficient than insertion sort.

But there are many cases where nobody cares.

> At most it could be equally
> efficient, and even those cases are extremely rare.
>
> Why does this matter? Because when you are using this kind of O(n^2)
> algorithm to speed up quicksort, you need to potentially run it
> hundreds, if not thousands of times for all those small partitions, and
> any additional comparison/assignment counts with respect to speed.

Here you are right.

Jean-Claude Arbaut wrote:
> Actually I had not the accelerated quicksort in mind. If you really
> have 20 elements to sort, bubblesort will do the job. Not the
> fastest, but still enough.

I simply can't understand why you would use bubble sort even if you
had to sort 20 elements once per minute.

Insertion sort is easier to understand than bubble sort, at least as
easy to implement, doesn't require any more coding and, for what it's
worth, is more efficient (could be good to take into account some future
situation where that one minute interval gets for some reason reduced to
one millisecond interval).

Then there's the philosophical aspect of it: If you use bubble sort by
principle, especially in an open source software which others may see,
you will be perpetuating this horrible algorithm and possibly teaching
bad habits to others. Insertion sort, on the other hand, is a beautiful
and efficient sorting algorithm for small arrays. So why not use it?
There are tons of reasons to prefer it over bubble sort, and absolutely
no reason to prefer the latter.

>> Insertion sort is one of the best possible O(n^2) algorithm for that
>> situation.
>
> Bubble sort is O(n^2)

A rather horrible one at that.

Juha Nieminen wrote:
> Jean-Claude Arbaut wrote:
>> Actually I had not the accelerated quicksort in mind. If you really
>> have 20 elements to sort, bubblesort will do the job. Not the
>> fastest, but still enough.
>
> I simply can't understand why you would use bubble sort even if you
> had to sort 20 elements once per minute.
>
> Insertion sort is easier to understand than bubble sort, at least as
> easy to implement,

Matter of taste.

> doesn't require any more coding and, for what it's
> worth, is more efficient (could be good to take into account some future
> situation where that one minute interval gets for some reason reduced to
> one millisecond interval).

Obviously, possible future evolution must be taken into account.
But it's not always relevant.

>
> Then there's the philosophical aspect of it: If you use bubble sort by
> principle, especially in an open source software which others may see,
> you will be perpetuating this horrible algorithm and possibly teaching
> bad habits to others.

Well, if others just copy it, they deserve what they get.

> Insertion sort, on the other hand, is a beautiful
> and efficient sorting algorithm for small arrays.

You see ? _Beautiful_. A matter of taste. I like bubbles. You don't like
bubbles.

> So why not use it?

Because I like bubbles

> There are tons of reasons to prefer it over bubble sort, and absolutely
> no reason to prefer the latter.

There is one. I like bubbles ! And it actually happened, that I had
a sorting algo to implement stright away, and I wrote a bubble sort
since it was really not the most important part of the program.
I see no harm.

>
>>> Insertion sort is one of the best possible O(n^2) algorithm for that
>>> situation.
>> Bubble sort is O(n^2)
>
> A rather horrible one at that.

A funny one.

thomas.mertes@gmx.at writes:

> On 27 Aug., 15:49, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> thomas.mer...@gmx.at writes:
>> > Lisp fans just don't get it that compile-time type checking has
>> > advantages.
>>
>> Why did they implement compile-time type checking in open source
>> compilers such as sbcl then?
>
> Is the compile-time type checking mandatory or optional?
> Is it necessary to define all variables/parameters with a type
> specification?
> Do the type checks also include function results?
>
>> > Other Lisp fans think that the syntax of a function call is the same
>> > as the syntax of an operator call.
>>
>> In lisp it is the case, and it is a discriminant advantage for what
>> lisp wants to do.
>
> The normal understanding of operators (at least for some
> mathematical ones) is that they are infix and have a priority
> and an associativity. This is not the case with Lisp function
> calls. Logically operator and function calls are the same but
> not syntactically.

This is not true. Mathematically, + is a binary function, that is, a
ternary relation with some specific properties. Idem for *. There is
no priority in their definition, much less any "infixity".
Associativity is indeed a mathematical property, but it's independant
of these irrelevant concepts.

+ : NxN --> N
(x,y) |-> +(x,y) ; yes, you can write it like any
; other mathematical function.

The "syntax" your math teacher taught you is of absolutely no
significance, mathematically.


>> > Lisp fans have argued that Lisp has overloadable user definable
>> > operators with priority and assoziativity and their solution would
>> > require to write a whole parser with read macros.
>>
>> You are inconsistent. * If you make extravagant demands on lisp, we
>> have the tools and hooks needed to implement them. *If you make honest
>> demands on lisp, we have easy and well integrated solutions.
>
> I do not make any demands on Lisp. This is just what some lisp
> fan told me how overloadable user definable infix operators with
> priority and assoziativity could be implemented in Lisp. But this
> is nothing special: A parser that translates from one representation
> (infix operator syntax with priority and associativity) to another
> (lists) can be written in any language.
>
> For Seed7 overloadable user definable infix operators with priority
> and assoziativity are not an extravagant demand. Naturally this
> is supported by Seed7. No need to write a parser.
>
> Now you can choose between:
> - This is a stupid feature
> - Lisp has it also built in

I choose: "This is a stupid feature".

Syntax is just irrelevant.

Free your mind fron irrelevant details like syntax!

In lisp, we don't use syntax. We work directly with the parse tree.
The way we write lisp is not some code syntax, it's the way lisp
LITERAL DATA is written. It's like if Kerningham realized he could
generate C code without having to implement the C lexer and parser, by
just implementing by hand a quick-and-dirty "parser" for the C data
syntax: {"if",{"==","a","b"},{"printf","\"equal\""},{"prin tf,"\"%d
vs. %d\"",a,b}} this data being read immediately into the parse tree,
and C code being generated from it.

The advantage of writting code as data of course being to be able to
easily manipulate code as data, since code is data.

By the way, the true syntax for lisp code is M-expressions:

fact[x]=eql[x;1]->1;T->times[x;fact[minus[x;1]]];


>> > Even if overloading, priority and assoziativity could be managed,
>> > compile-time type checking would still be missing.

Now, when you have a parse tree, you don't need priority of
operators, since the order of application of the operators is
explicitely given by their position in the parse tree.


>> Compile time type checking is orthogonal. *I don't see the beginning
>> of an argument.
>
> The argument is that writing a parser with read macros is not
> enough because mandatory compile-time type checking
> (although orthogonal) would still be an open issue.

But still no problem. A lot of languages, different from Lisp, were
implemented first in Lisp. Notably Haskell.

> BTW.: Types and overloading are related.
>
>> > And: If you have to write a whole parser
>> > with read macros macros this would be a new language and
>> > not Lisp.
>>
>> This is the point of lisp. *What do you thing the expression
>> "meta-programming" means?
>
> Syntax and semantic are two different things.
> Being able to support the semantic of new language constructs
> is not the same as being able to support the syntax of new
> language constructs. While Lisp can support many language
> constructs with new invented semantics it is necessary to write
> a parser to support a new syntax.

Yes, but it is also useless to support a new syntax.


> Seed7 supports constructs with new syntax and new semantic.
> It is not necessary to write a parser to support a new
> syntactic construct.

Well, Seed7 supports irrelevant and useless features.

Be happy!
--
__Pascal Bourguignon__ http://www.informatimago.com/

READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.

On 28 Aug., 09:34, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> thomas.mer...@gmx.at writes:
> > On 27 Aug., 15:49, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> thomas.mer...@gmx.at writes:
> >> > Lisp fans just don't get it that compile-time type checking has
> >> > advantages.
>
> >> Why did they implement compile-time type checking in open source
> >> compilers such as sbcl then?
>
> > Is the compile-time type checking mandatory or optional?
> > Is it necessary to define all variables/parameters with a type
> > specification?
> > Do the type checks also include function results?

No answer.

> >> > Other Lisp fans think that the syntax of a function call is the same
> >> > as the syntax of an operator call.
>
> >> In lisp it is the case, and it is a discriminant advantage for what
> >> lisp wants to do.
>
> > The normal understanding of operators (at least for some
> > mathematical ones) is that they are infix and have a priority
> > and an associativity. This is not the case with Lisp function
> > calls. Logically operator and function calls are the same but
> > not syntactically.
>
> This is not true. Mathematically, + is a binary function, that is, a
> ternary relation with some specific properties. Idem for *. There is
> no priority in their definition, much less any "infixity".
> Associativity is indeed a mathematical property, but it's independant
> of these irrelevant concepts.

QED.
Concept not present in Lisp -> Seen as irrelevant by a Lisp fan.

> * * + : NxN *--> N
> * * * *(x,y) |-> +(x,y) ; yes, you can write it like any
> * * * * * * * * * * * * ; other mathematical function.

The notation above is not a proper list.
The symbols : --> and |-> look like bad bad infix operators/symbols.
You use the concepts you see as irrelevant yourself.

> The "syntax" your math teacher taught you is of absolutely no
> significance, mathematically.

The infix syntax of arithmetic operators if teached by all
math teachers in the world. Therefore most people will
recognize and understand it without problems.

> >> > Lisp fans have argued that Lisp has overloadable user definable
> >> > operators with priority and assoziativity and their solution would
> >> > require to write a whole parser with read macros.
>
> >> You are inconsistent. * If you make extravagant demands on lisp, we
> >> have the tools and hooks needed to implement them. *If you make honest
> >> demands on lisp, we have easy and well integrated solutions.
>
> > I do not make any demands on Lisp. This is just what some lisp
> > fan told me how overloadable user definable infix operators with
> > priority and assoziativity could be implemented in Lisp. But this
> > is nothing special: A parser that translates from one representation
> > (infix operator syntax with priority and associativity) to another
> > (lists) can be written in any language.
>
> > For Seed7 overloadable user definable infix operators with priority
> > and assoziativity are not an extravagant demand. Naturally this
> > is supported by Seed7. No need to write a parser.
>
> > Now you can choose between:
> > *- This is a stupid feature
> > *- Lisp has it also built in
>
> I choose: "This is a stupid feature".
>
> Syntax is just irrelevant.

QED.
Concept not present in Lisp -> Seen as irrelevant by a Lisp fan.

> Free your mind fron irrelevant details like syntax!

In the above sentence you use a ! because of syntax rules.

> In lisp, we don't use syntax. *We work directly with the parse tree.
> The way we write lisp is not some code syntax, it's the way lisp
> LITERAL DATA is written. *It's like if Kerningham realized he could
> generate C code without having to implement the C lexer and parser, by
> just implementing by hand a quick-and-dirty "parser" for the C data
> syntax: *{"if",{"==","a","b"},{"printf","\"equal\""},{"pri ntf,"\"%d
> vs. %d\"",a,b}} this data being read immediately into the parse tree,
> and C code being generated from it.
>
> The advantage of writting code as data of course being to be able to
> easily manipulate code as data, since code is data.

While code as data is a good concept it is not necessary to
write everything as list. The goal of code as data can also be
reached without the restrictions of Lisp.

> By the way, the true syntax for lisp code is M-expressions:
>
> * *fact[x]=eql[x;1]->1;T->times[x;fact[minus[x;1]]];
>
> >> > Even if overloading, priority and assoziativity could be managed,
> >> > compile-time type checking would still be missing.
>
> Now, when you have a parse tree, *you don't need priority of
> operators, since the order of application of the operators is
> explicitely given by their position in the parse tree.

Guess how the internal representation of a Seed7 program
(call code) looks like.

> >> Compile time type checking is orthogonal. *I don't see the beginning
> >> of an argument.
>
> > The argument is that writing a parser with read macros is not
> > enough because mandatory compile-time type checking
> > (although orthogonal) would still be an open issue.
>
> But still no problem. *A lot of languages, different from Lisp, were
> implemented first in Lisp. *Notably Haskell.

A lot of languages were implemented in C. Does this make C
superior to them?

> > BTW.: Types and overloading are related.
>
> >> > And: If you have to write a whole parser
> >> > with read macros macros this would be a new language and
> >> > not Lisp.
>
> >> This is the point of lisp. *What do you thing the expression
> >> "meta-programming" means?
>
> > Syntax and semantic are two different things.
> > Being able to support the semantic of new language constructs
> > is not the same as being able to support the syntax of new
> > language constructs. While Lisp can support many language
> > constructs with new invented semantics it is necessary to write
> > a parser to support a new syntax.
>
> Yes, but it is also useless to support a new syntax.

QED.
Concept not present in Lisp -> Seen as useless by a Lisp fan.

> > Seed7 supports constructs with new syntax and new semantic.
> > It is not necessary to write a parser to support a new
> > syntactic construct.
>
> Well, Seed7 supports irrelevant and useless features. *

Such as
object orientated programming
interfaces and dynamic dispatch
multiple dispatch
abstract data types
predefined container types
arbitrary precision integers
user defined operators and statements
overloading of operators and statements
templates without special syntax
mandatory compile-time type checking
exceptions
compilable to C
portability

Probably you wanted to say that the features not present in Lisp
are irrelevant and useless.

BTW.: I wrote also another article in this thread as reponse to an
article from you.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

thomas.mertes@gmx.at writes:

> On 28 Aug., 09:34, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> This is not true. Mathematically, + is a binary function, that is, a
>> ternary relation with some specific properties. Idem for *. There is
>> no priority in their definition, much less any "infixity".
>> Associativity is indeed a mathematical property, but it's independant
>> of these irrelevant concepts.
>
> QED.
> Concept not present in Lisp -> Seen as irrelevant by a Lisp fan.
>
>> * * + : NxN *--> N
>> * * * *(x,y) |-> +(x,y) ; yes, you can write it like any
>> * * * * * * * * * * * * ; other mathematical function.
>
> The notation above is not a proper list.
> The symbols : --> and |-> look like bad bad infix operators/symbols.
> You use the concepts you see as irrelevant yourself.

You lose. You didn't recognize the difference between the notation
and the concept. The notation I used is irrelevant (but this is what
you releved). The concept I presented was the important part, and you
ignored it.

Would you prefer this representation of the concept:

+ | 0 1 2 3 4 5 6 7 ...
---+----------------------------------
0 | 0 1 2 3 4 5 6 7 ...
1 | 1 2 3 4 5 6 7 8 ...
2 | 2 3 4 5 6 7 8 9 ...
3 | ...
...


>> The "syntax" your math teacher taught you is of absolutely no
>> significance, mathematically.
>
> The infix syntax of arithmetic operators if teached by all
> math teachers in the world. Therefore most people will
> recognize and understand it without problems.

These mathematical notations are not universal, either in space nor
time. That's why all the math teachers I ever had always started with
their own version of the definitions and notations they used. Thanks
to Bourbaki, they were quite homogenous, but to take an example,
there are more than thirty different set of mathematical notations
just for boolean algebra.


>> Free your mind fron irrelevant details like syntax!
>
> In the above sentence you use a ! because of syntax rules.

When a finger points at the moon the fool looks at the finger.


>> In lisp, we don't use syntax. *We work directly with the parse tree.
>> The way we write lisp is not some code syntax, it's the way lisp
>> LITERAL DATA is written. *It's like if Kerningham realized he could
>> generate C code without having to implement the C lexer and parser, by
>> just implementing by hand a quick-and-dirty "parser" for the C data
>> syntax: *{"if",{"==","a","b"},{"printf","\"equal\""},{"pri ntf,"\"%d
>> vs. %d\"",a,b}} this data being read immediately into the parse tree,
>> and C code being generated from it.
>>
>> The advantage of writting code as data of course being to be able to
>> easily manipulate code as data, since code is data.
>
> While code as data is a good concept it is not necessary to
> write everything as list. The goal of code as data can also be
> reached without the restrictions of Lisp.

Well show us an example.


But I didn't mention lists. I said data.

The difference between data and code is that there is a direct
correspondance between the syntax you write in your text files and the
data structures built by the system when it reads that data. This is
helped by a simple syntax (so simple it doesn't need the heavy
machinery of a scanner generator and much less of a parser generator).
This also means a uniform representation of all the program elements.
We don't use a different type of data to represent a IF than to
represent a user function call. Using the same data structure for all
the elements of the parse thre allows an easy manipulation of that
parse tree by automatic tools (ie editors, macros, interpreters,
compilers), and the easy development of these tools by mere
programmers. In lisp we don't need a grand priest from the compiler
church to manipulate our programs, any student can implement his own
lisp compiler.



>> By the way, the true syntax for lisp code is M-expressions:
>>
>> * *fact[x]=eql[x;1]->1;T->times[x;fact[minus[x;1]]];
>>
>> >> > Even if overloading, priority and assoziativity could be managed,
>> >> > compile-time type checking would still be missing.
>>
>> Now, when you have a parse tree, *you don't need priority of
>> operators, since the order of application of the operators is
>> explicitely given by their position in the parse tree.
>
> Guess how the internal representation of a Seed7 program
> (call code) looks like.

Well if it is some kind of s-expressions, why do you hide it from us?


>> >> Compile time type checking is orthogonal. *I don't see the beginning
>> >> of an argument.
>>
>> > The argument is that writing a parser with read macros is not
>> > enough because mandatory compile-time type checking
>> > (although orthogonal) would still be an open issue.
>>
>> But still no problem. *A lot of languages, different from Lisp, were
>> implemented first in Lisp. *Notably Haskell.
>
> A lot of languages were implemented in C. Does this make C
> superior to them?

I meant 'easily' in addition to 'first'.
Were they implemented in C easily?


>> > BTW.: Types and overloading are related.
>>
>> >> > And: If you have to write a whole parser
>> >> > with read macros macros this would be a new language and
>> >> > not Lisp.
>>
>> >> This is the point of lisp. *What do you thing the expression
>> >> "meta-programming" means?
>>
>> > Syntax and semantic are two different things.
>> > Being able to support the semantic of new language constructs
>> > is not the same as being able to support the syntax of new
>> > language constructs. While Lisp can support many language
>> > constructs with new invented semantics it is necessary to write
>> > a parser to support a new syntax.
>>
>> Yes, but it is also useless to support a new syntax.
>
> QED.
> Concept not present in Lisp -> Seen as useless by a Lisp fan.

But you are wrong here! The concept is useless, but for people like
you, and for end-users, the concept IS present in lisp, thru reader
macros and you can always implement a scanner, or use a scanner
generator.

>> > Seed7 supports constructs with new syntax and new semantic.
>> > It is not necessary to write a parser to support a new
>> > syntactic construct.
>>
>> Well, Seed7 supports irrelevant and useless features. *
>
> Such as

You are silly. "There exist x in S such as P(x)" doesn't mean that
"for all x in S, P(x) holds".


And you are also silly because:
Lisp
> object orientated programming check
> interfaces and dynamic dispatch check
> multiple dispatch check
> abstract data types check
> predefined container types check
> arbitrary precision integers check
> user defined operators and statements check
> overloading of operators and statements check
> templates without special syntax check
> mandatory compile-time type checking no
> exceptions check
> compilable to C check
> portability check

Much more check

Lisp has all these features. If you wanted to add compile-time type
checking, why didn't you just add that feature to Common Lisp, it
would have been much less work that try to invent a new language.


--
__Pascal Bourguignon__ http://www.informatimago.com/

PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.