
Dear Haskellers, do you think that Haskell is a 3GL (third generation language) or a 5GL or that the hierarchy of programming language generations is useless? I see a problem if the potential of a language is evaluated according to the generation it belongs to. 1GLs: machine languages 2GLs: assembler languages 3GLs: programming based on algorithms (C, Java, ...) 4GSs: domain-specific languages (SQL,...) 5GLs: automatic problem solving (Mathematica, Prolog,...) and/or visual programming (Visual Basic,...) Haskell's laziness would in principle permit programming in a style akin to Prolog, e.g., for parser combinators. The question is: how strong is the influence of laziness in everyday Haskell programming? Cheers -- Christoph

Bulat Ziganshin wrote:
Hello Ch.,
Monday, September 25, 2006, 5:14:15 PM, you wrote:
do you think that Haskell is a 3GL (third generation language) or a 5GL or
it's a BottomthGL language :)
That's a religious statement. I was looking for some strong arguments for the nonbelievers that Haskell is a 5GL. Cheers -- Christoph

"Ch" == Ch A Herrmann
writes: it's a BottomthGL language :) Ch> That's a religious statement. I was looking for some strong Ch> arguments for the nonbelievers that Haskell is a 5GL. But what about nonbelievers in language classification by generation? As already mentioned you can write algorithms in Haskell (3GL), embed a DSL in it and write a program in that DSL or in several DSLs (4GL). AFAIK Mathematica is not a logic programming language, thus all its features can be implemented in Haskell as library, will be Haskell a 5GL in this case?
-- WBR, Max Vasin.

"Ch" == Ch A Herrmann
writes: it's a BottomthGL language :)
Ch> That's a religious statement. I was looking for some strong Ch> arguments for the nonbelievers that Haskell is a 5GL. But what about nonbelievers in language classification by generation? As already mentioned you can write algorithms in Haskell (3GL), embed a DSL in it and write a program in that DSL or in several DSLs (4GL). AFAIK Mathematica is not a logic programming language, thus all its features can be implemented in Haskell as library, will be Haskell a 5GL in this case I'm looking for an honest classification. The aim of the GLs is, as I think, the degree of abstraction. The question is, how much *intelligence* provided by preprocessing, libraries etc. is permitted. Personally, I think Haskell should be a 5GL because Prolog is a 5GL. What Prolog really provides concerning automatic problem solving is little: equation solving in term algebra; you can simulate that in Haskell without much effort. On the other hand, I saw Haskell classified as a 3GL. The problem is that Haskell often exposes
Max Vasin wrote: the algorithmic structure. What people often forget is that Prolog programs in non-trivial situations are likely to fail if you do not prescribe the evaluation order, by features like the cut which destroy the declarative semantics. People also forget that arithmetic constraints in Prolog have to be directed (input/output variables), no difference to Haskell. My argumentation is: Prolog is a 5GL & Haskell is more abstract than Prolog => Haskell is a 5GL Some of the language features in Haskell that contribute to this abstraction are: laziness, pattern matching with guards, list comprehensions, type classes Please note that this is not a philosophic discussion. If Haskell is a 3GL, than it is at the same level with Java and since Java is more common, people think they should always use Java. Haskell as a 5GL will tell people: this is a language in which you can solve problems simpler and safer and it will encourage people to try to solve problems instead of resigning due to the complexity of the problem. Cheers -- Christoph

On Mon, 2006-09-25 at 22:22 +0200, Christoph Herrmann wrote: . . .
What Prolog really provides concerning automatic problem solving is little: equation solving in term algebra; you can simulate that in Haskell without much effort. On the other hand, I saw Haskell classified as a 3GL. The problem is that Haskell often exposes the algorithmic structure. What people often forget is that Prolog programs in non-trivial situations are likely to fail if you do not prescribe the evaluation order, by features like the cut which destroy the declarative semantics. People also forget that arithmetic constraints in Prolog have to be directed (input/output variables), no difference to Haskell.
I spent some time working on a large Prolog application where performance was critical, and it became obvious that when a Prolog program is tuned by removing non-determinism it moves towards a functional program. Any real (non-textbook example) Prolog program has to expose algorithmic details simply because the programmer must a) make decisions and b) express them. I think you're right that Haskell should be in the same bag as Prolog. -- Bill Wood

Hello Bill, Tuesday, September 26, 2006, 1:03:02 AM, you wrote:
I spent some time working on a large Prolog application where performance was critical, ... I think you're right that Haskell should be in the same bag as Prolog.
and Haskell is the same as C++ when performance is critical, while C++ is the same as assembler. believe me - i has experience of optimizing both Haskell and C++ programs :) i think it's wrong to make decisions about language expressiveness on the base of requirements for writing optimized programs. my _application_ Haskell/C++ code contains about 80-90%% of code that _don't need_ to be optimized and it's just the case when higher language expressiveness rules. but for the remaining 10-20%% optimizing of higher-level language becomes a nightmare and it is much better to use lower-level language in these places (if it's possible!) instead of using lower-level techniques that just don't fit in the higher-language toolbox :( ps: btw, i was really thinking in assembler when optimizing my Haskell lib. it is why it so fast. on good-old DEC cpus whole getChar/putChar actions may be compiled in just one asm instruction :) so, using your logic, Haskell is 1-gl language :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Mon, 25 Sep 2006, Christoph Herrmann wrote:
I'm looking for an honest classification. The aim of the GLs is, as I think, the degree of abstraction. The question is, how much *intelligence* provided by preprocessing, libraries etc. is permitted. Personally, I think Haskell should be a 5GL because Prolog is a 5GL. What Prolog really provides concerning automatic problem solving is little: equation solving in term algebra; you can simulate that in Haskell without much effort. On the other hand, I saw Haskell classified as a 3GL. The problem is that Haskell often exposes the algorithmic structure. What people often forget is that Prolog programs in non-trivial situations are likely to fail if you do not prescribe the evaluation order, by features like the cut which destroy the declarative semantics. People also forget that arithmetic constraints in Prolog have to be directed (input/output variables), no difference to Haskell.
Compare Haskell with Computer algebra systems, where you can write root equations, and the system tells you the set of solutions. CAS let you write some infinite sum or integral, things that cannot be solved by brute force, and the system simplifies that to a fraction of pi or so. This is non-trivial and you would have to program a lot in Haskell to achieve this.
My argumentation is: Prolog is a 5GL & Haskell is more abstract than Prolog => Haskell is a 5GL
Or Prolog is better classified as 3GL. :-)
Some of the language features in Haskell that contribute to this abstraction are: laziness, pattern matching with guards, list comprehensions, type classes
Pattern matching with guards is not more than a 'switch', list comprehension is syntactic sugar, some type relations are available in all OO languages. What remains special is laziness, higher order functions. (Did I forget something?) Indeed, these features allow for more abstraction. Maybe we could classify Haskell as 3.5 GL or so. :-)
Please note that this is not a philosophic discussion. If Haskell is a 3GL, than it is at the same level with Java and since Java is more common, people think they should always use Java. Haskell as a 5GL will tell people: this is a language in which you can solve problems simpler and safer and it will encourage people to try to solve problems instead of resigning due to the complexity of the problem.
So classification is a marketing issue? A higher level of abstraction can also scare people, if they expect efficiency. I also know Java freaks who stay away from Haskell, because they find it too abstract.

-----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- bounces@haskell.org] On Behalf Of Christoph Herrmann Sent: 25 September 2006 21:22 To: Max Vasin Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Re: Is Haskell a 5GL? ...
What Prolog really provides concerning automatic problem solving is little: equation solving in term algebra; you can simulate that in Haskell without much effort.
Could you, or anyone else, elaborate a bit on how to emulate Prolog in Haskell? For example, I remember that in Prolog you can write a concat function that can be used to concatenate two lists as well as to split them: concat([1,2] ,[3,4] ,Z) --> Z = [1,2,3,4] concat([1,2] ,Y ,[1,2,3,4]) --> Y = [3,4] Now, that's powerful. How would you do that in Haskell? Regards, Titto

Here is a paper on how to do logic programming in Haskell
Deals with a logic puzzle and how the haskell and prolog solutions compare
http://web.engr.oregonstate.edu/~erwig/zurg/
In terms of automated theorem proving here is another paper
http://citeseer.ist.psu.edu/cache/papers/cs/5363/http:zSzzSzwww.ki.informati...
Regards
David
On 26/09/06, Pasqualino 'Titto' Assini
-----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- bounces@haskell.org] On Behalf Of Christoph Herrmann Sent: 25 September 2006 21:22 To: Max Vasin Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Re: Is Haskell a 5GL? ...
What Prolog really provides concerning automatic problem solving is little: equation solving in term algebra; you can simulate that in Haskell without much effort.
Could you, or anyone else, elaborate a bit on how to emulate Prolog in Haskell?
For example, I remember that in Prolog you can write a concat function that can be used to concatenate two lists as well as to split them:
concat([1,2] ,[3,4] ,Z) --> Z = [1,2,3,4] concat([1,2] ,Y ,[1,2,3,4]) --> Y = [3,4]
Now, that's powerful. How would you do that in Haskell?
Regards,
Titto
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- It chews up lies and spits out the gristle of truth http://liveatthewitchtrials.blogeasy.com/

Hello Max, Monday, September 25, 2006, 10:41:20 PM, you wrote: Ch>> That's a religious statement. I was looking for some strong Ch>> arguments for the nonbelievers that Haskell is a 5GL.
But what about nonbelievers in language classification by generation?
i was not on the market when 1..3 GLs arrived, but i've seen 4/5 GL story and it was just marketing tool. 4gl was used to market task-specific languages embedded in some applications or used to quickly build applications, such as Clarion Database Developer. this name was used just to emphasize advantages of these laguages over general-purpose (3gl) ones in the areas that was targeted by these languages when Japan supercomputing/new programming paradigm was arrived, it was also marketed as 5 gl - not because it's superior to 4gl, but just because 4'th number was already used :) Japan project failed its goals, and logic programming don't ruled the world. but in some sense you can say that 5gl was about describing the problem instead of the way to solve it (algorithm=3gl), so FP is closer to this goal than C++ or Java -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hi, an experienced person at our lab told me that the classification into generations has become unfashioned in the last decade; thus I think I will stay away from using it but argue with concrete abstraction features. Concerning the point someone made about the features of Haskell: * pattern matching: just case distinction * list comprehensions: syntactic sugar These are indeed local syntactic issues but the amount of such small things is essential to make things easy, in addition to semantic issues like laziness. Assume that you do not have them: then your programs would look as verbose as Java or LISP programs. If someone asks me for the generation level of Haskell, I will say 5, because there are only a few small functions you have to add to implement a small theorem prover; provocatively speaking: if these were in the prelude than Haskell was an artificial intelligence language. But perhaps such marketing statements are not convincing any more. -- Christoph

Hello Ch., Wednesday, September 27, 2006, 7:31:00 PM, you wrote:
thus I think I will stay away from using it but argue with concrete abstraction features.
Concerning the point someone made about the features of Haskell: * pattern matching: just case distinction * list comprehensions: syntactic sugar
some time i will write "Haskell advertisement" wiki. key Haskell selling points i plan to mention is its expressiveness, reliability, excellent support for concurrency while higher-order funcs, parameterized ADTs, polymorphism, laziness, immutable data and various other language features are just concrete Haskell instruments that allow to reach these universal programmers goals meanwhile, i recommend you to look into "why Haskell matters" and http://www.md.chalmers.se/~rjmh/Papers/whyfp.pdf -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Wed, 27 Sep 2006, Ch. A. Herrmann wrote:
Concerning the point someone made about the features of Haskell: * pattern matching: just case distinction * list comprehensions: syntactic sugar These are indeed local syntactic issues but the amount of such small things is essential to make things easy, in addition to semantic issues like laziness.
According to http://haskell.org/haskellwiki/History_of_Haskell two main styles of functional programming have established: "Declaration style" and "Expression style". The features you emphasize support to the declaration style. I prefer mostly the expression style and I don't feel I'm missing something important.
Assume that you do not have them: then your programs would look as verbose as Java or LISP programs.
The notation [f x | x <- xs] describes operations on list elements, and looks like the imperative "forall x in xs do f x", whereas map f xs is a list transformation. The second one is more abstract, isn't it?

Hi, Henning Thielemann wrote:
...
The notation [f x | x <- xs] describes operations on list elements, and looks like the imperative "forall x in xs do f x", whereas map f xs is a list transformation. The second one is more abstract, isn't it?
for that simple example yes, but what's about list comprehensions like: sequence of parsers: (p <+> q) r = [ (f (x,y), r2) | (x, r1) <- p r, (y, r2) <- q r1 ] or triples: [ (x,y,z) | x<-[1..n], let x2=x*x, y<-[1..x], let y2=y*y, let z=isq (x2,y2), x2+y2==z*z ] or database queries: [ (name,salary) | ((_,name),dateofbirth,((Just salary))) <- table, dateofbirth>1980 && salary>100000 ] I just typed these examples but did not check them. There are many other examples like n queens, functions on shaped matrices etc. Cheers -- Christoph

On Thu, 5 Oct 2006, Ch. A. Herrmann wrote:
Henning Thielemann wrote:
...
The notation [f x | x <- xs] describes operations on list elements, and looks like the imperative "forall x in xs do f x", whereas map f xs is a list transformation. The second one is more abstract, isn't it?
for that simple example yes, but what's about list comprehensions like:
sequence of parsers: (p <+> q) r = [ ((x,y), r2) | (x, r1) <- p r, (y, r2) <- q r1 ]
More abstract: p <+> q = runStateT (liftM2 (,) (StateT p) (StateT q)) If you give the parsers the StateT type, then it is even <+> = liftM2 (,)
or triples: [ (x,y,z) | x<-[1..n], let x2=x*x, y<-[1..x], let y2=y*y, let z=isq (x2,y2), x2+y2==z*z ]
This is rather a 1:1 translation of an imperative program, a bit shorter, ok, but it will certainly not impress an imperative programmer. I find it more important that the generation of pairs, where the first element is smaller than the second one, can be nicely separated from the Pythagoras check, due to laziness.

Hi,
3GLs: programming based on algorithms (C, Java, ...) There are algorithms in Haskell
4GSs: domain-specific languages (SQL,...) There are plenty of domain specific languages in Haskell, I'd call Parsec one of them
5GLs: automatic problem solving (Mathematica, Prolog,...) I wouldn't say it "automatically" solves the problems. But I would say that the high degree of abstraction and compositionality afforded by a pure language means that its easy to reuse other peoples solutions, which I guess is having it automatically solved.
and/or visual programming (Visual Basic,...)
I can only assume you are a) joking, or b) not a visual basic user. While Visual Basic is a much insulted language, I have a soft spot for it. However, its not a Visual programming language - its a language which happens to have a GUI API and a bit of IDE support. Its resolutely a 3GL, roughly akin to Java, in my opinion.
The question is: how strong is the influence of laziness in everyday Haskell programming? I'd say very strong, lots of times a "where" is used thats making use of laziness.
Thanks Neil

Hi,
and/or visual programming (Visual Basic,...)
I can only assume you are a) joking
a bit, yes
, or b) not a visual basic user.
also true
While Visual Basic is a much insulted language, I have a soft spot for it. However, its not a Visual programming language - its a language which happens to have a GUI API and a bit of IDE support. Its resolutely a 3GL, roughly akin to Java, in my opinion.
I'd agree but I found the info in the web
The question is: how strong is the influence of laziness in everyday Haskell programming?
I'd say very strong, lots of times a "where" is used thats making use of laziness.
I don't agree: "where" is often only used to program in a top-down style Cheers -- Christoph

"Ch" == Ch A Herrmann
writes:
Ch> Hi, Hello,
I'd say very strong, lots of times a "where" is used thats making use of laziness.
Ch> I don't agree: "where" is often only used to program in a top-down Ch> style I would say in a "more declarative" style, the "where" is closer to thinking of the program as a set of equations (as opposed to "let"). -- WBR, Max Vasin.

On Mon, 25 Sep 2006, Ch. A. Herrmann wrote:
Dear Haskellers,
do you think that Haskell is a 3GL (third generation language) or a 5GL or that the hierarchy of programming language generations is useless? I see a problem if the potential of a language is evaluated according to the generation it belongs to.
1GLs: machine languages 2GLs: assembler languages
assembly language (Assembler ist deutsch :-)
3GLs: programming based on algorithms (C, Java, ...) 4GSs: domain-specific languages (SQL,...) 5GLs: automatic problem solving (Mathematica, Prolog,...) and/or visual programming (Visual Basic,...)
Visual Basic and Computer Algebra Systems in the same generation?
Haskell's laziness would in principle permit programming in a style akin to Prolog, e.g., for parser combinators. The question is: how strong is the influence of laziness in everyday Haskell programming?
Actually, laziness allows me to formulate algorithms that look more like the specification of the problem than the solution. E.g., I can formulate the solution of a differential equation in terms of a power series or time series in that way. However I have to put some effort into formulating it in a way that works. E.g. I'm only able to solve such equations if it is possible to express the second derivative in terms of the first and the zeroth one. Computer algebra systems are essentially better here.

Hi, Henning Thielemann wrote:
assembly language (Assembler ist deutsch :-)
for mysterious reasons it entered the English world.
3GLs: programming based on algorithms (C, Java, ...) 4GSs: domain-specific languages (SQL,...) 5GLs: automatic problem solving (Mathematica, Prolog,...) and/or visual programming (Visual Basic,...)
Visual Basic and Computer Algebra Systems in the same generation?
Ok, let Visual Basic be a 3GL.
Haskell's laziness would in principle permit programming in a style akin to Prolog, e.g., for parser combinators. The question is: how strong is the influence of laziness in everyday Haskell programming?
Actually, laziness allows me to formulate algorithms that look more like the specification of the problem than the solution.
That would be a 4GL.
E.g., I can formulate the solution of a differential equation in terms of a power series or time series in that way. However I have to put some effort into formulating it in a way that works.
That's kind of developing an algorithm. -- Christoph

Hallo,
On 9/25/06, Ch. A. Herrmann
Hi,
Henning Thielemann wrote:
assembly language (Assembler ist deutsch :-)
for mysterious reasons it entered the English world.
'Assembly' is a language. 'Assembler' is a program. -- -alex http://www.ventonegro.org/

Alex Queiroz wrote:
On 9/25/06, Ch. A. Herrmann
wrote:
Henning Thielemann wrote:
assembly language (Assembler ist deutsch :-)
for mysterious reasons it entered the English world.
'Assembly' is a language. 'Assembler' is a program.
All this is absolutely essential for the progress of Humanity... But, anyway, "Assembler" was the official name of the assembly language of IBM 360/370 if I am not mistaken. And I believe that it infiltrated die Deutsche Sprache therefrom. Good followers of Konrad Duden called a compiler: Uebersetzer, so perhaps the assemblers had here and there some Wagnerian names as well... (For the CDC mainframes the assembly language was called Compass [Comprehensive Assembler]. It was a 7648764GL. You could program in it almost like in Lisp thanks to some very exquisite macros, and add another set of macros which performed some type checking and optimized the register allocation. People who used it got famous (as M. Veltman, Nobel prize in physics), or got mad.) OK, who next?...

On Mon, 2006-09-25 at 16:50 +0200, Jerzy Karczmarczuk wrote: . . .
(For the CDC mainframes the assembly language was called Compass [Comprehensive Assembler]. It was a 7648764GL. You could program in it almost like in Lisp thanks to some very exquisite macros, and add another set of macros which performed some type checking and optimized the register allocation. People who used it got famous (as M. Veltman, Nobel prize in physics), or got mad.)
And there was something exquisitely perverse about writing Compass programs as Fortran subroutines so you could avoid writing IO in Peripheral Processor code. -- Bill Wood

The official name of the assembler for 360/370 was BAL (basic assembly language). I wrote code in it back in prehistoric times <g>. Murray Gross Brooklyn College On Mon, 25 Sep 2006, Jerzy Karczmarczuk wrote:
Alex Queiroz wrote:
On 9/25/06, Ch. A. Herrmann
wrote: Henning Thielemann wrote:
assembly language (Assembler ist deutsch :-)
for mysterious reasons it entered the English world.
'Assembly' is a language. 'Assembler' is a program.
All this is absolutely essential for the progress of Humanity...
But, anyway, "Assembler" was the official name of the assembly language of IBM 360/370 if I am not mistaken. And I believe that it infiltrated die Deutsche Sprache therefrom. Good followers of Konrad Duden called a compiler: Uebersetzer, so perhaps the assemblers had here and there some Wagnerian names as well...
(For the CDC mainframes the assembly language was called Compass [Comprehensive Assembler]. It was a 7648764GL. You could program in it almost like in Lisp thanks to some very exquisite macros, and add another set of macros which performed some type checking and optimized the register allocation. People who used it got famous (as M. Veltman, Nobel prize in physics), or got mad.)
OK, who next?... _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, Sep 25, 2006 at 03:27:32PM +0200, Henning Thielemann wrote: Hi Henning,
Actually, laziness allows me to formulate algorithms that look more like the specification of the problem than the solution. E.g., I can formulate the solution of a differential equation in terms of a power series or time series in that way. However I have to put some effort into formulating it in a way that works. E.g. I'm only able to solve such equations if it is possible to express the second derivative in terms of the first and the zeroth one. Computer algebra systems are essentially better here.
In my experience, most people use CAS interactively: they encounter an integral or a PDE that's difficult to solve, so they type it into Mathematica (which frequently cannot solve it either, then you go crazy, numerical, or both ;-). It is more like a sophisticated symbolic calculator with a lot of patterns built in for manipulating expressions. Mathematica has features of a programming language, but most people I know are not using those when manipulating formulas, and conversely, when _programming_ in Mathematica (ie writing code and then executing it do so something repetitive) they rarely do anything symbolic. CAS are great for specific purposes, especially for replacing those tomes which have solutions of equations/ODEs/PDEs/integrals etc in them, and some CAS have Algol-style flow control and numerical methods which you can use for solving numerical problems, but the two are almost never mixed. Best, Tamas

I've used Mathematica a lot (and, unfortunately, still using it), and
written a program, which uses symbolic computations a lot to deal with
simplification of multivariate polynomial systems of inequalities. Now I'm
trying to get rid of that Mathematica code and rewrite the program in
Haskell because writing and debugging a program in Mathematica which is more
complex than doing some simple computations is a mess.
Nevertheless, Mathematica is a great product, especially if you know how to
get what you want from it.
Ivan
On 9/30/06, Tamas K Papp
On Mon, Sep 25, 2006 at 03:27:32PM +0200, Henning Thielemann wrote:
Hi Henning,
Actually, laziness allows me to formulate algorithms that look more like the specification of the problem than the solution. E.g., I can formulate the solution of a differential equation in terms of a power series or time series in that way. However I have to put some effort into formulating it in a way that works. E.g. I'm only able to solve such equations if it is possible to express the second derivative in terms of the first and the zeroth one. Computer algebra systems are essentially better here.
In my experience, most people use CAS interactively: they encounter an integral or a PDE that's difficult to solve, so they type it into Mathematica (which frequently cannot solve it either, then you go crazy, numerical, or both ;-). It is more like a sophisticated symbolic calculator with a lot of patterns built in for manipulating expressions.
Mathematica has features of a programming language, but most people I know are not using those when manipulating formulas, and conversely, when _programming_ in Mathematica (ie writing code and then executing it do so something repetitive) they rarely do anything symbolic.
CAS are great for specific purposes, especially for replacing those tomes which have solutions of equations/ODEs/PDEs/integrals etc in them, and some CAS have Algol-style flow control and numerical methods which you can use for solving numerical problems, but the two are almost never mixed.
Best,
Tamas _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Tamas K Papp writes:
Henning Thielemann wrote:
Actually, laziness allows me to formulate algorithms that look more like the specification of the problem than the solution. E.g., I can formulate the solution of a differential equation in terms of a power series or time series in that way. However I have to put some effort into formulating it in a way that works. E.g. I'm only able to solve such equations if it is possible to express the second derivative in terms of the first and the zeroth one. Computer algebra systems are essentially better here.
In my experience, most people use CAS interactively: they encounter an integral or a PDE that's difficult to solve, so they type it into Mathematica (which frequently cannot solve it either, then you go crazy, numerical, or both ;-). It is more like a sophisticated symbolic calculator with a lot of patterns built in for manipulating expressions.
I should have reacted earlier... Please don't exaggerate with *opposing* CAS and Haskell, Prolog, or other *universal* languages. CAS such as Maple, Mupad, and also Mathematica in a sense are also universal, but they simply have * enormous libraries permitting to deal with symbolic expressions ; * Pattern matching/rewriting contraptions useful to manipulate deeply intricate structures. All this CAN BE DONE in Haskell as well, but reinventing the wheel is rarely interesting (sometimes is, though) (*). Still CAS are no magic, and - getting back to Henning's example: No CAS will give you the power expansion of a solution of a differential equation if you can't algorithmize the needed recurrencies. But if you can, then you can do it in a numerical setting using Haskell or something else. Haskell allows you to apply laziness in a "perverse" way as well, for example solving - as a power series - a *singular* equation (Bessel), where you define the first derivative through the function and its second derivative, although at first glance this seems mad. But look here, a quite old stuff... : Theor. Comp. Sci. 187,(1997), pp. 203--219. on-line : http://users.info.unicaen.fr/~karczma/arpap/lazysem.pdf page 4... Jerzy Karczmarczuk ======= (*) A reference for your culture: Jorge Luis Borges, "Pierre Ménard, the Author of Don Quixote". It is a story about a person who WROTE (not: copied) a book, exactly, letter by letter, identical to the book of Cervantes. It was identical, but having been written another time/place, and addressed to different readers, it had a different *deep meaning*, it was a different novel. Or was it?...

On Sat, 30 Sep 2006 jerzy.karczmarczuk@info.unicaen.fr wrote:
Tamas K Papp writes:
In my experience, most people use CAS interactively: they encounter an integral or a PDE that's difficult to solve, so they type it into Mathematica (which frequently cannot solve it either, then you go crazy, numerical, or both ;-). It is more like a sophisticated symbolic calculator with a lot of patterns built in for manipulating expressions.
I should have reacted earlier... Please don't exaggerate with *opposing* CAS and Haskell, Prolog, or other *universal* languages. CAS such as Maple, Mupad, and also Mathematica in a sense are also universal, but they simply have
* enormous libraries permitting to deal with symbolic expressions ; * Pattern matching/rewriting contraptions useful to manipulate deeply intricate structures.
All this CAN BE DONE in Haskell as well, but reinventing the wheel is rarely interesting (sometimes is, though) (*).
I think that "CAN BE DONE" is not the point, because everything can be done in assemb ... erm ... machine code. If I tell OOP people about the features of Haskell, they say, they can do the same in principle with their languages. The languages are all Turing-complete, but this statement is as useful as the observation "a line segment contains as many points as a filled square" for measuring lengths and areas. On the other hand, since we have clarified that language generations are a marketing issue, I will not defend this classification scheme or any classification with it. If at all, we should respect that Haskell is a class of its own. ;-)

Ch. A. Herrmann wrote:
do you think that Haskell is a 3GL (third generation language) or a 5GL or that the hierarchy of programming language generations is useless?
I did a literature search on language generations a few years ago when I was preparing the first incarnation of the local Principles of Programming Languages course. There were three findings: 1) I could not find where the idea comes from. 2) All sources agree what 1GL, 2GL and 3GL are. 3) There is no consensus on what 4GL and 5GL are. (Different sources define them completely differently.) Hence, I just classify all current general-purpose languages as 3GL and consider the classification mostly meaningless for today's languages.
participants (16)
-
Alex Queiroz
-
Antti-Juhani Kaijanaho
-
Bill Wood
-
Bulat Ziganshin
-
Ch. A. Herrmann
-
Christoph Herrmann
-
David Curran
-
Henning Thielemann
-
Ivan Tarasov
-
Jerzy Karczmarczuk
-
jerzy.karczmarczuk@info.unicaen.fr
-
Max Vasin
-
Murray Gross
-
Neil Mitchell
-
Pasqualino 'Titto' Assini
-
Tamas K Papp