Browse thread
Locally-polymorphic exceptions [was: folding over a file]
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | skaller <skaller@u...> |
| Subject: | Re: [Caml-list] Unsoundness is essential |
On Thu, 2007-10-04 at 17:29 +0200, Andrej Bauer wrote: > Skaller, you want something like this: > > (a) expressive power (dependent types, subsets, you-name-it) > > (b) soundness, in the following form: > * the compiler rejects obvious nonsense > * the result of a compilation is a program and a list of > assertions which the compiler was unable to verify Yes, I want something like that. > This I would call "controlled unsoundness" As an (eX) motorcyclist I can agree .. riding a bike is like having one continuous controlled road accident.. :) > which at least allows the > human to see what needs to be verified to guarantee soundness. It's much > better than the sort of unsoundness that skaller seems to be advocating. Sure, but my point does remain: the expressiveness is more or less paramount. It is not so much that I personally desire it or not, but that real programmers in the real world go out there and do whatever is necessary to make programs work. If you can produce a compiler with an expressive type system but cannot yet create a complete list of unproven assertions, that is still better than writing Python. In fact I write a lot of Python even now. I do not do so in ignorance of the value of static type checking! There is a good reason I choose it, for example for the Felix build system. It is not because I fear writing all the types Ocaml would require, but because the need for 'dynamic typing' in this kind of software and the lack of expressiveness in Ocaml type system makes Ocaml unsuitable. Please note I'm *trying* to explain the reason, but probably haven't got it right. The point is, in the manifesto it should go like: expressiveness first, then generating proof obligations, and also with time, improving the automatic provers. The key thing is not to restrict expressiveness just because the type system cannot fully cope.. making the typing more expressive has many benefits by itself. A stupid one: how can theoreticians test the efficacy of a new algorithm with real world case data? -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net