>This figure seems pretty meaningless to me. Static type checking fans >(including myself) like to trot out the very small examples that show >that given some type signature it is nearly impossible to write a >buggy function that passes type checking. However, I am currently >writing my first somewhat significant program in SML (on the order of >a few thousand lines of code) and I assure that it is very easy to >write a large SML program that passes the type checker, but doesn't do >what one would like it to do.
Yes, certainly. And I think anyone who's written a big program in SML would agree. But there is certainly an advantage to knowing that there won't be any runtime errors (other than exceptions you've raised yourself). Bugs in SML tend to have a lot more to do with the problem at hand than the details of whether that line of code really does what you think it does, if that makes any sense.
Torbjorn Lager wrote: > h...@rentec.com (HP) wrote in message > <news:10caf2e2.0303011458.3b3ee50b@posting.google.com>... >> By reading Erlang's website, >> I (being a C++ person) notice that >> one feature in Erlang is 'hot code replacement' ---- >> i.e. change the code while the application is running. >> This is one feature that I always wanted in some situations >> at work.
>> Does any functional language support this feature ? >> (e.g. Does Mozart/Oz or Lisp support it ?)
Correct me if I'm wrong, but I believe that Common Lisp have had this for years.
> Bugs in SML tend to have a lot more to do with the problem at hand > than the details of whether that line of code really does what you > think it does, if that makes any sense.
Indeed it does. Now I must share a trivial anecdote about a nasty bug during my complete-newbie experiments with Haskell. It was exactly one of these "doesn't do what I think" problems, and I'm still scarred from it :-)
I was writing a Haskell program to solve a combinatorial puzzle. I had an algorithm that I knew was correct, coded it up, got it past the type checker, and ran it. It gave me an answer, and I patted myself on the back.
A little while later I was looking over it again, and discovered that the answer, though plausible, was wrong. I reread the program many times but was convinced it was correct. So I started running only part-way and then manually checking its state, and did this for a long time because the program got a long way before entering an incorrect state.
Finally I narrowed it down to one tiny function, and saw the problem: an operator precedence bug. IIRC, I had written:
if a then x else [] ++ if b then y else []
When I meant:
(if a then x else []) ++ (if b then y else [])
Or something very similar. Not fun at all!
So, nothing profound, and I certainly don't mean to suggest that Haskell is bad - I've shown the code to other people, who spotted the problem instantly. But, my own earnest attempts to get this "programs that just work" glory have been a bit bumpy in these early days. Maybe someone else can commiserate :-)
> It is only proven to be type-correct (of course), but in practice it > is 98% of the time correct as in 'has no bugs'. Don't confuse the two. > Of course static type checking can never *prove* that the program is > completely bug free, and no sane person would claim this.
Static-type checking 100% gurantees that some program faitfully implements a specification.
val f: int -> int
is a specification in ML that states when "f" is given an integer value if it returns a value the value is an integer.
In other more sophisticated languages (Coq for example) you can write the type specification
val f: \forall i:int. i -> fact(i)
where fact is a specification of the factorial function. If "f" does indeed have the type \forall i:int. i -> fact(i) then it meets the specification.
So types allow you to verify many non-trivial properties. The properties you enforce are limited only by the sophistication of the specification language, and the patience of the programmer who baiscally has to force his program through the type-checker by constructing what amounts to a formal proof.
So if you have a clearly defined specification that is expressible in your type system and your program type checks and your type system is sound of course. You can be 100% guaranteed your program is "bug free" if we define "bug freeness" to be any program that faithfully implements the specification.
Of course the *specification* may have bugs, but a type system can't do anything about that. In fact there's not much you can do about any design level bugs, other than build in fault tolerance.
As a practical matter, the ability to specify "interesting" non-trivial properties conviently in a type system is a big area of open research. However, it's just a matter of time when every program will come with a proof of correctness and we can spend our time debuging design level bugs rather than program level bugs. All the tools are there, we're just missing the right abstractions and approiate proof engineering skills to pull this off. I'll be surprised if this doesn't happen within the next 100 years.
jm...@cornell.edu (Jeffrey M. Vinocur) writes: {stuff deleted}
> Yes, certainly. And I think anyone who's written a big program > in SML would agree. But there is certainly an advantage to > knowing that there won't be any runtime errors (other than > exceptions you've raised yourself). Bugs in SML tend to have a > lot more to do with the problem at hand than the details of > whether that line of code really does what you think it does, if > that makes any sense.
You don't really appreciate the power of types, until you write non-trivial programs in Twelf, Coq, or NuPRL.
I think it's the case that the newest version of Twelf could acutally verify total correctness of the theorem prover. If the prover was complete for the logic it was trying to prove.
People should be careful and not confuse theorem proving with checking the validity of a proof. Theorem proving in general is impossible. Checking the validity of a proof is so simple a computer can do it!
> People should be careful and not confuse theorem proving with checking the > validity of a proof. Theorem proving in general is impossible. Checking the > validity of a proof is so simple a computer can do it!
Then again, writing the proof in such a form that the computer can check it is often more complicated than checking it by hand...
On Wed, 5 Mar 2003 00:39:26 +0000 (UTC), Lauri Alanko wrote: > nospam+dcw...@agere.com (Daniel C. Wang) quoth: > > People should be careful and not confuse theorem proving with checking the > > validity of a proof. Theorem proving in general is impossible. Checking the > > validity of a proof is so simple a computer can do it!
> Then again, writing the proof in such a form that the computer can check > it is often more complicated than checking it by hand...
I haven't found it so. Writing (machine-checkable) proofs is exactly like writing programs -- lemmas are just functions on proofs, after all. After having written a couple BIGNUM machine-checkable proofs, I actually prefer them. There are no hidden assumptions or hand-waves to trip you up.
> You don't really appreciate the power of types, until you write > non-trivial programs in Twelf, Coq, or NuPRL.
This is one way you can get to appreciate the power, but why isn't it obvious that this does not have to come at the price of reduced appreciation for dynamic typing? ML would be wonderful for some big project involving many people etc, but I would still prefer my pet dynamically typed language with heavy abuse of dynamic typing for scripts and personal hacks. And even if you do like static typing for scripts (at least one person here uses Nuprl for scripting), you would probably not go as far as proving them correct: given the job you want to get done it is usually not worth the extra time. In the same way, given the jobs I want to get done with my scripts and relying on my programming skills more, I find it quicker to not use static typing.
: This reminds me of the story of an aircraft that crashed due to a : failure in the navigation system. The plane tried to flip over as it : crossed the equator, due to a sign error in the code. : I imagine that if you have some code that has passed a static type : checker then changing an integer N somewhere in the program to -N : probably won't have any effect on the types.
Depends on whether your type system differentiates between an integer and a positive integer. But even just knowing that it is an integer might be a nice step toward finding this sort of bug.
: Problem 1: Getting the types right = a soluble problem : Problem 2: Getting the values right = a much more difficult problem : IMHO there seem to be two many people doing (1) and not enough doing (2)
One of these can be done automatically, the other requires work. It's not surprising which one is more commonly done. However, you should have more time to spend on 2 if 1 is done for you.
: - there also seems to be a vociferous sub-set of people working on : (1) who seems to think that they have also solved (2).
It would be nice to have a type system that sophisticated, but I don't see it anywhere yet. (In fact, in the full sense of what you're saying, it's undecidable anyway) The thing is, though, that there is a sliding scale from 1 to 2, depending on the strength/scope of the type system, and the more we can incorporate into 1, the less effort is required to do 2, so hopefully the more programmers will bother to do it.
:> i still see no advantage to delaying type error detection to run-time. : Unless the advantages of a dynamic type system outweigh the : advantages of a static type system. For example, Unix pipes and : sockets are just uninterpreted streams of characters (i.e. untyped) : but are still *very* useful (compare this with say XML/WSDL/SOAP : streams which are strongly (I use the word guardedly) typed) - each : have advantages in different contexts.
Uninterpreted streams gain an advantage from not making you interpret them. Isn't that orthogonal to whether they are statically typed?
:> On the (+) side with dynamic typing code is shorter and you can :> write powerful generic routines for common tasks. :> What did you mean by this? That is, to get back to (what i see as) the :> root of the matter, what practical advantages are offered by dynamic type :> systems? : The code for the generic operations is small and easy to implement : directly. it's nice to have generic libraries, which are a lot smaller : than specialized encoding routines for every specific data type.
Surely this is an argument for polymorphic typing, not dynamic?
gr...@cs.uwa.edu.au writes: > Eli Barzilay <e...@barzilay.org> wrote: > : given the jobs I want to get done with my scripts and relying on my > : programming skills more, I find it quicker to not use static typing.
> Could you give an example of where static typing slows you down?
Yes -- there are many common examples, like not needing the extra syntax involved in sum types option, or the well chewed printf thing, or the basic philosophical issue of being forced to do a lot of designing before you start coding etc. But I don't think that going through explicit examples will do any good -- everyone knows them and most have prepared counter speaches (and counter counter speaches and...). No wonder so many threads here end up with some version of the current subject line.
> Then again, writing the proof in such a form that the computer can check > it is often more complicated than checking it by hand...
Actually it's simple. You just write down your assumptions on what the code does. If the checker is good, it should be enough to write down loop invariants (or their equivalent for recursion - is there a beast called "recursion invariant"?). The computer should be able to fill the gaps between the invariants, I think that's just propositional logic (which has nasty worst-case complexities but is usually straightforward).
Just my personal theory - could anybody confirm or disprove it?
Regards, Joachim -- This is not an official statement from my employer.
Eli Barzilay <e...@barzilay.org> wrote: >> Could you give an example of where static typing slows you down? > Yes -- there are many common examples, like not needing the extra > syntax involved in sum types option,
What extra syntax? Do you never specify what kinds of values your functions accept? How are others supposed to know how to use them? Type definitions are a tiny one-time effort (< 5% of code) and, besides allowing rigorous automated checks, provide unambiguous documentation, too.
Btw., you can also use polymorphic variants (e.g. as implemented in OCaml). Then you don't even need to define the type: the compiler infers automatically, what kinds of values your functions accept.
Sure, when mixing various types (strings, floats, etc.) in one datastructure (e.g. a list), you'll have to tag them, but... - when accessing them, you'll need to explicitly check their type in dynamically typed languages anyway to handle them as required! No win here...
> or the well chewed printf thing,
printf is also available in OCaml...
> or the basic philosophical issue of being forced to do a lot of > designing before you start coding etc.
Really? When writing large programs, you'd be well advised to do a lot of designing anyway. And for short programs: no, you are not forced to do this. I also write scripts using OCaml and never felt like having to design more or less than, say, in Perl. Indeed, the static type system almost always finds some silly bugs in them. Languages with modern type systems greatly _encourage_ good design, but they won't point a gun at you if you don't do it. They'll just shoot you when you cause type errors - for good reason.
This is exactly the response I was trying to avoid. So the question is: are you really expecting an unexpected reply -- something that will have any un-re-re-re-hashed content? I'm not taking the easy way out -- you want to, I will reply, I just think it will go down a known path.
Adrian Hey <a...@NoSpicedHam.iee.org> writes: > Ulf Wiger wrote:
> > : I've looked at the Concurrent Haskell paper, and think it > > : looks fairly promising. It also indicates that one can > > : combine static typing with an elegant concurrency model.
> > I'm utterly convinced that you need strong concurrency > > support, including distribution and process monitoring > > in order to build e.g. telecoms systems. I'm not yet > > convinced that static typing would provide a net benefit > > for such systems, but that obviously depends on the > > entire programming environment and how the tools are > > applied in the project.
> I've been following this thread and trying to figure out why > you regard strong static typing, as implemented in modern FPL's > (not static typing as in Pascal say) as a feature which is > detrimental to concurrency.
I'm obviously not expressing myself clearly. I apologize. I was trying to explain how I've not seen a compelling reason why you couldn't make a statically typed language implementation that also has strong concurrency support.
Perhaps I should also clarify this: I don't invent programming languages; I only use them. As long as I can't find a statically typed programming environment that has concurrency support to rival that of Erlang, and preferrably also a comparable assortment of middleware components, my choice is easy.
I can not give you an explanation for why such an environment (to my knowledge) doesn't exist today, other than that it's not been sufficiently interesting to the community of language designers who'd be capable of pulling it off.
> I don't know any Erlang, so what is it about Erlang concurrency > that you think can't be handled by static type systems? The two > issues seem quite unrelated to me.
If you really want to find a feature of Erlang that's difficult for a statically typed language, then it would be hot code replacement. I've read some papers about how it could be done, and they were complicated enough that I didn't bother to understand them in detail. I did grasp that it was mainly a theoretical argument at this point.
I'm willing to concede that there is no law of nature that says it can't be done. From a practical point of view, there are certainly other ways of achieving in-service upgrade of an entire system, esp. if that system has redundancy (which it always has, or the in-service upgrade requirement is moot.) In short, you don't have to do it the Erlang way, if that's too difficult.
> Static typing is arguably detrimental to other aspects of > dynamic programming, concurrent or otherwise. Is that what > you're really worried about?
No, I'm worried about pushing products to the market that I can sell for real money, knowing that 80% of the life-cycle cost of these products lies in maintenance, and I have to accept the fact that I often have to hire programmers fresh out of college to perform maintenance on other people's code. I need strong support for whatever programming language I decide to use, and I need good libraries. While it's interesting to engage in debates about whether one could do things differently, the alternatives need to be viable enough that I could do some relevant prototyping in the near future; otherwise, it's not really on my map.
(Although the fact that I'm participating in this discussion might be seen as an indicator that I'm not really quite that dogmatic... at least not all the time.)
> > I would like to think that I'm open to convincing > > real-world examples demonstrating the power of static > > typing(*), but then again, 10 years of programming in > > a dynamically typed language probably induces some bias...
> Well my experience is that static typing is so incredibly > useful I'm surprised anybody doubts the benefits.
Is static typing so useful that no other considerations are needed? Should I go to Corporate Management and ask them to bet their next billion-dollar project on a statically typed language because... static typing is obviously useful?
Or are you saying there are no drawbacks?
I'm saying that I consider strong concurrency support to be more critical in my domain than static typing. This doesn't mean that the two couldn't be combined -- it just means that if I have to choose (and at the moment it seems I do), between static typing and strong concurrency support, I would choose the latter any day and twice on a Sunday.
> I'm also sceptical that even thorough testing can reliably > detect type errors.
Well, what matters in our world is how often our customers suffer service interruption. We measure those things, and the target for us is 99.999% availability or better. Currently, we are better than that.
> As for finding "real-world examples demonstrating the power of > static typing", I suspect you will find none. I don't think > static type systems do increase the power of non-broken > programs. They just make it far less likely that broken > programs will be created.
I was referring to experiences from product development using such languages. Did the product come out in time, on budget, and with sufficient quality? How much (tounge in cheek) did static typing contribute? How about maintenance? Programmer training (learning curve)? Stuff like that.
(Anyone who doesn't want to be convinced will always find ways to question any such arguments, but some will listen; without them, you will have a hard time convincing people in industry, even those who would want to be convinced. Then there are always people who are willing to be guinea pigs. We were for Erlang.)
Regards, UW -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes
Adrian Hey <a...@NoSpicedHam.iee.org> writes: > Joe Armstrong wrote: > > Problem 1: Getting the types right = a soluble problem > > Problem 2: Getting the values right = a much more difficult problem
> > IMHO there seem to be two many people doing (1) and not enough doing > > (2) - there also seems to be a vociferous sub-set of people working on > > (1) who seems to think that they have also solved (2).
> AFAICS the people you are attacking exist only in your imagination. > I don't know of any advocate of static type systems who has made such > a claim. Would you care to provide references? Links? c.l.f threads?
I have often hear this claim - 20 seconds in google provides statements like:
In article <1992Jul14.205627.25...@eng.umd.edu> c...@eng.umd.edu (Charles Lin) writes:
--- quote ---- - In ML most of the errors are discovered at compile time. As a rule of thumb one can say that an ML program usually works after it is compiled whereas in LISP you have to test your functions on some trivial data first.
---- end ----
I assume "works" means what I call "getting the values right".
I can *easily* write incorrect programs with correct types
In Erlang I guess that we could prove that:
factorial(0) -> 1; factorial(N) -> N * factorial(N-2).
is of type int -> int
But it's still wrong.
> Your view seems to be that static typing should not be used at all > because it fails to eliminate all program bugs. If so, this seems pretty > illogical and unconvincing to me.
Well if I'd said that it would, indeed be "illogical and inconvincing" - but this is not my view, and I have never said that. What I wrote in my last posting was:
> > Please don't mis-represent me - type checking is great to have - one of > > many good techniques that is needed to make reliable systems.
Which means exactly what it says and nothing else.
> The argument that static typing should not be used in Erlang because > it would be incompatible with a lot of existing code is much more > convincing to me. But that's a problem with Erlang, not with static > typing or other statically typed FPL's.
But I have never argued this - since nobody has been able to make a static type system for all of Erlang the question of what to do with legacy code has never arisen - (type systems for sub-sets of Erlang have been made but never for the full language) -
My view is that if we could add a post-hock type system to Erlang I would encourage people to use it.
I assume by "problem" you mean academic problem (i.e. nobody knows how to do it). It's certainly not a practical problem or anything that is inhibiting the spread of the language -
I have something new to report in this long-running debate.
Last time we had this debate, one of the advantages pointed out by dynamic typing advocates was that dynamically typed languages let you execute code which was not yet complete, without needing to manually write stubs for the unimplemented procedures.
My news is that the latest release-of-the-day versions of Mercury include support for this. If you compile with the new `--allow-stubs' option, the compiler will only report a warning (rather than an error) about procedures for which there are no clauses. Any calls to such procedures will of course throw an exception at run-time.
So now at least one statically typed language gives programmers the ability to execute code that is not yet complete, without needing to manually write stubs.
-- Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
>--- quote ---- >- In ML most of the errors are discovered at compile time. As a rule >of thumb one can say that an ML program usually works after it is >compiled whereas in LISP you have to test your functions on some >trivial data first.
>---- end ----
>I assume "works" means what I call "getting the values right".
>I can *easily* write incorrect programs with correct types
(snip)
There might be a big "YMMV" here: the types of bugs that I introduce tend to be such that they cause a type error. However, I know that this is not true for a number of other good programmers with whom I've been acquainted: their bugs seem to be type safe! So, I find it quite plausible that Charles Lin's statement will be correct for some people, like me, but not at all for others. That is, it may not be so much what you can do, as what you tend to do.
Mark Carroll <ma...@chiark.greenend.org.uk> writes: > In article <tyf4r6i6kjc....@enfield.sics.se>, Joe Armstrong <j...@enfield.sics.se> wrote: >>In article <1992Jul14.205627.25...@eng.umd.edu> c...@eng.umd.edu (Charles Lin) writes: >>--- quote ---- >> In ML most of the errors are discovered at compile time. As a rule >> of thumb one can say that an ML program usually works after it is >> compiled whereas in LISP you have to test your functions on some >> trivial data first. >>---- end ---- > There might be a big "YMMV" here: the types of bugs that I introduce > tend to be such that they cause a type error.
I would say that I *definitely* catch most errors compile time. It's possible that the errors caught there would be trivial to find and fix at run time too -- many of the errors that do get through the type checker are, IME, notoriously hard.
Perhaps Joe intended to emphasize the 'rule of thumb'? Which, incidentally, I also think is a rather weak statement -- and one which I have no trouble agreeing with: More often than not, when I get my functions type correct, they are also semantically correct.
>> I assume "works" means what I call "getting the values right". >> I can *easily* write incorrect programs with correct types
So can I, but I usually don't. :-)
It seems there is violent agreement that:
a) strong types are generally beneficial b) other features may be better, depending on the application c) type correct /= semantically correct
OTOH, I'm very curious about why the concurrent-static language attempts floundered; can anybody shed a light on that?
-kzm -- If I haven't seen further, it is by standing in the footprints of giants
> Perhaps I should also clarify this: I don't invent programming > languages; I only use them. As long as I can't find a statically > typed programming environment that has concurrency support to > rival that of Erlang, and preferrably also a comparable assortment > of middleware components, my choice is easy.
> I can not give you an explanation for why such an environment > (to my knowledge) doesn't exist today, other than that it's not > been sufficiently interesting to the community of language > designers who'd be capable of pulling it off.
You might be interested in Alice then. It's an ongoing project to add static typing to Mozart/Oz (which carries claims on concurrency support that sound very similar to those on Erlang). (I say "claim" not because I want to imply scepticism, but because I have never looked too deeply into the concurrency stuff of either language and can't confirm it.)
Regards, Joachim -- This is not an official statement from my employer.
Ulf Wiger wrote: > Adrian Hey <a...@NoSpicedHam.iee.org> writes: >> Well my experience is that static typing is so incredibly >> useful I'm surprised anybody doubts the benefits.
> Is static typing so useful that no other considerations are > needed?
No, of course not. But there's no reason why other considerations should prevent the use of static type systems in principle. In practice the other considerations (such as concurrency support) may cause people to chose Erlang. But IMO this will be despite, not because of, it's lack of static type security.
> Should I go to Corporate Management and ask them to > bet their next billion-dollar project on a statically typed > language because... static typing is obviously useful?
Why not? I'm not asserting that any other language suitable for your needs currently exists. But then again, I can see no reason to dismiss any future candidates on the grounds that they provide a static type system.
> Or are you saying there are no drawbacks?
Yes, IMO there are no drawbacks with using a strong static type system. AFAICS the use of a static (compile time) type checking does not prevent the use dynamic typing where needed (or maybe even unsafe, unchecked type cast hackery). Both Clean & Haskell (ghc) provide some support for dynamic typing. Whether either are currently adequate for whatever purpose I don't know.
> I'm saying that I consider strong concurrency support to be > more critical in my domain than static typing. This doesn't > mean that the two couldn't be combined -- it just means that > if I have to choose (and at the moment it seems I do), between > static typing and strong concurrency support, I would choose > the latter any day and twice on a Sunday.
Fair enough, we all have to make pragmatic choices. For my professional needs all currently available FPL implementations suck. But maybe things won't always be that way.
It seems like the gist of what you're saying is that you might prefer an Erlang with a modern static type system and the only thing stopping you using such a thing is that nobody has produced a sufficiently polished implementation. So maybe the right thing to do is to beg Erlang implementors (whoever they are) for a better Erlang, not to advertise this particular wart as a feature :-)
Joe Armstrong wrote: > In article <1992Jul14.205627.25...@eng.umd.edu> c...@eng.umd.edu (Charles > Lin) writes:
> --- quote ---- > - In ML most of the errors are discovered at compile time. As a rule > of thumb one can say that an ML program usually works after it is > compiled whereas in LISP you have to test your functions on some > trivial data first.
> ---- end ----
> I assume "works" means what I call "getting the values right".
This is a perfectly reasonable statement about ML, though it might not be entirely fair to Lisp. It is clearly not an assertion that problem (2) has been solved by the use of a static type system.
But from my own experience using Haskell (and I think other Haskeller's will concur) I can say that my programs rarely fail because of some fundamental flaw in the program design or logic. If they fail it's usually silly "finger trouble" errors like supplying arguments in the wrong order or using a list when a list of lists is required. These errors usually (not *always*) manifest themselves as type errors detected by the compiler.
Fergus Henderson wrote: > I have something new to report in this long-running debate.
> Last time we had this debate, one of the advantages pointed out > by dynamic typing advocates was that dynamically typed languages > let you execute code which was not yet complete, without needing > to manually write stubs for the unimplemented procedures.
> My news is that the latest release-of-the-day versions of Mercury > include support for this. If you compile with the new `--allow-stubs' > option, the compiler will only report a warning (rather than an error) > about procedures for which there are no clauses. Any calls to such > procedures will of course throw an exception at run-time.
> So now at least one statically typed language gives programmers the > ability to execute code that is not yet complete, without needing to > manually write stubs.
Yes but this a whole lot away from the dynamic coding process that is common in dynamically typed languages.
If I start coding I run my environment (Xanalys LispWorks in this case) and incrementally add functionality. The feature of testing incomplete programs allows me to verify my code from the first line on. If I accidently hit a place where my code is not complete enough I get help from the environment to resolve the issues. If I change my design the environment helps me migrating to the new design while staying in the live image.
When in production I can fix things in the running application that I did not even plan to make "dynamically fixable".
I think dynamic systems can make finding unexpected bugs *alot* easier because they tend to have more information available at runtime.
So while this new feature of the Mercury compiler may indeed be a good idea it is far from being comparable to what the same feature means for a dynamic language.
f...@students.cs.mu.OZ.AU (Fergus Henderson) writes: > Last time we had this debate, one of the advantages pointed out > by dynamic typing advocates was that dynamically typed languages > let you execute code which was not yet complete, without needing > to manually write stubs for the unimplemented procedures.
True. I do that all the time. Very useful feature when designing large systems.
> My news is that the latest release-of-the-day versions of Mercury > include support for this. If you compile with the new `--allow-stubs' > option, the compiler will only report a warning (rather than an error) > about procedures for which there are no clauses. Any calls to such > procedures will of course throw an exception at run-time.
> So now at least one statically typed language gives programmers the > ability to execute code that is not yet complete, without needing to > manually write stubs.
Nice. (:
/Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes
