What do you LISPers think of Haskell?

Vend wrote:

> C is statically typed but type-unsafe, among other kind of unsafe
> "features" it has.
> C++ is as unsafe as C and, due to its object orientation model, not
> completely statically typed, but the language doesn't insert any
> runtime dynamical type checks, so this is another source of unsafety.

Do you have a C++ example, where object orientation makes it not completely
statically typed? And for runtime dynamical checks in C++, take a look at
http://www.google.com/search?q=c%2B%2B+rtti

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On 2008-08-20, DeverLite <derby.little@gmail.com> wrote:
> Right. Thanks for the clarification. I didn't mean to imply that there
> was no typing by default in lisp: just that it wasn't something you
> had to *declare*.

Static type systems that require declarations are not state-of-the-art. A
statically typed language isn't defined as one which requires everything to be
declared prior to use. The requirement for explicit declarations merely
reflects 1960's state-of-the-art in static typing (even though it happens to be
a feature of some programming languages designed in the 1990's).

On 2008-08-28, Vend <vend82@virgilio.it> wrote:
> C is statically typed but type-unsafe, among other kind of unsafe
> "features" it has.

Some of the reasons that C is type unsafe are very good, to the point that a
language which doesn't allow the same flexibility is a useless pile of crap
for any real-world software development.

> C++ is as unsafe as C and, due to its object orientation model, not
> completely statically typed, but the language doesn't insert any
> runtime dynamical type checks, so this is another source of unsafety.

That is false. C++ has dynamic checks in the dynamic_cast conversion
operator. If a class pointer is converted using dynamic_cast, the result may be
a null value, which must be checked by the program. If a reference is
converted, then a bad_cast exception may be thrown.

Of course, you can use an unsafe conversion operator which doesn't have checks.

> Java has an OO model similar to that of C++ (but simplified) and it's
> type-safe.

From Java, you can call a native platform function. That function can do
anything: crash your kernel, reformat your hard drive, blow up your video
card with bad parameters, etc.

No language whose definition allows for some kind of undefined behavior
(in the place of which an extension may be provided) can be called safe.

Without the ability to call native platform functions, a programming
environment is a crippled pile of shit, unsuitable for anything but coding
acadamic examples.

> I don't have statistics, but I presume that this happens less
> frequently than type errors in completely dynamically typed languages
> like Lisp or Python.

Right, you don't have statistics, but you presume.

> (I'm not claiming that Java is better than Lisp or Python, I'm just
> comparing this aspect).

I.e. comparing your lack of statistics about Java to your lack of statistics
about Lisp and python.

On 29 Ago, 00:37, Frank Buss <f...@frank-buss.de> wrote:
> Vend wrote:
> > C is statically typed but type-unsafe, among other kind of unsafe
> > "features" it has.
> > C++ is as unsafe as C and, due to its object orientation model, not
> > completely statically typed, but the language doesn't insert any
> > runtime dynamical type checks, so this is another source of unsafety.
>
> Do you have a C++ example, where object orientation makes it not completely
> statically typed?

By "statically typed" I mean that the compiler is always able to prove
which types of values a variable, parameter or expression represent.

class Foo {...};
class Bar : public Foo {...};
class Baz : public Foo {...};

....

Foo * a;
if (unpredictableAtCompileTime()) {
a = new Bar();
}
else {
a = new Baz();
}

Which type of object is 'a' pointing to?

> And for runtime dynamical checks in C++, take a look athttp://www.google.com/search?q=c%2B%2B+rtti

Ok, but it's an optional feature.

> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de

On 28 Ago, 23:43, Pascal Costanza <p...@p-cos.net> wrote:
> Vend wrote:
> > On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> DeverLite <derby.lit...@gmail.com> writes:
> >>> [...] Although very flexible, and good at catching errors at compile
> >>> time, I found the typing system in Haskell sometimes got in the way.
> >>> Lisp let's you declare types, but if you don't want to you don't have
> >>> to, and this tends to make it more flexible than Haskell.
> >> Actually, what the lisp type system means is that in lisp we program
> >> in generic mode by default.
>
> >> When you write:
>
> >> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> >> it's statically typed, but it's also SPECIFICALLY typed.
>
> >> When you write in lisp:
>
> >> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> >> it's already a generic function (not a lisp generic function,
> >> technically, but what other programming languages call a generic
> >> function):
>
> >> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> >> --> (24 24.0 24.0L0 15/8)
>
> > But the mathematical factorial function is defined only on natural
> > numbers, hence this behavior is most likely incorrect.
>
> Who said that his definition is about the "mathematical factorial function"?
>
> > Moreover, in dynamically typed languages like Lisp there is the risk
> > of having a statement like this buried deep in your program:
>
> > (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> > ctrl-alt-shift-tab-right-mouse-button))
> > (setq bomb "goodbye")
> > (setq bomb 42))
>
> The risk is very low, unless you have total retards working on your code
> base.
>
> Pascal

My example was specifically written to make the flaw apparent, but are
you sure that these situations are rare in practice?

Have you ever seen a program which manages a collection of objects of
heterogeneous type, which isn't know at compile-time?

Now let's assume there is an operation done infrequently on some
objects of that collection, which works on all the possible types
except an infrequently occurring one.

Maybe the guy who wrote that operation wasn't aware of the existence
of that type, or wasn't thinking about it, or that type was added
later by someone not aware of the existence and contract of that
operation. It doesn't seem a very unlikely scenario does it?

Anyway the result will be an infrequent runtime type error which will
probably escape the testing.

> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/

On 29 Ago, 00:06, Kaz Kylheku <kkylh...@gmail.com> wrote:
> On 2008-08-28, Vend <ven...@virgilio.it> wrote:
>
>
>
> > On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> DeverLite <derby.lit...@gmail.com> writes:
> >> > [...] Although very flexible, and good at catching errors at compile
> >> > time, I found the typing system in Haskell sometimes got in the way.
> >> > Lisp let's you declare types, but if you don't want to you don't have
> >> > to, and this tends to make it more flexible than Haskell.
>
> >> Actually, what the lisp type system means is that in lisp we program
> >> in generic mode by default.
>
> >> When you write:
>
> >> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> >> it's statically typed, but it's also SPECIFICALLY typed.
>
> >> When you write in lisp:
>
> >> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> >> it's already a generic function (not a lisp generic function,
> >> technically, but what other programming languages call a generic
> >> function):
>
> >> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> >> --> (24 24.0 24.0L0 15/8)
>
> > But the mathematical factorial function is defined only on natural
> > numbers, hence this behavior is most likely incorrect.
>
> That is nonsense. The factorial function has generalizations which behave like
> factorial for the natural numbers.
>
> Remove foot from mouth and visit:
>
> http://en.wikipedia.org/wiki/Gamma_function

I'm aware of that function, which isn't what Pascal's code calculates.

> Of course, the above function isn't the gamma function.

Indeed.

> That's beside the
> point;

No, that's the point: You made an useless remark.

> we could fix FACT so that it computes the gamma in the general case, but
> is optimized using the factorial for special cases.

In which case it would be desirable to have two different definitions:
one for integers and one for reals, which means that generic
programming would be of no use.

> > Moreover, in dynamically typed languages like Lisp there is the risk
> > of having a statement like this buried deep in your program:
>
> Bombs can be buried in code written in any programming language.
>
> > (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> > ctrl-alt-shift-tab-right-mouse-button))
> > (setq bomb "goodbye")
> > (setq bomb 42))
>
> You can use any mainstream programming language to hide an easter egg that is
> activated by ctrl-alt-shift-tab-right-mouse-button, and other conditions.

You missed the point.
That was not an example of an easter egg, that was meant to illustrate
that type errors can occur in response to external input or complex
calculations in dynamical typed systems.

> > And then somewhere else a (fact bomb) makes your program crash and
> > your client angry.
>
> This is false. The program will not crash, but rather signal a condition, which
> is something different.

Ok. Let's say it will malfunction, ok?

> Type is simply being treated as a run-time value.
>
> Yes, when some run-time object has an invalid value, that is a programming bug.
> Congratulations on figuring that out!
>
> If types are not allowed to be run-time values, programmers invent ad-hoc type
> systems which use existing value representations (such as integral
> enumerations) as type.
>
> For instance, in the BSD operating system, open files are represented by a
> ``struct vnode''. That's the C language type, but there is a ``v_type'' field
> which can be, for instance, VDIR.
>
> Faced with the static programming language, the programmers have hacked up an
> ad-hoc, fragile form of dynamic typing which /really/ breaks if a critical type
> check is missing. There is no recoverable condition. What happens is that the
> kernel crashes, or worse: the filesystem becomes corrupt.
>
> Of course, the Lisp kernel is built on a foundation of static typing rigidity.
>
> Just like the BSD kernel, thanks to C static type checking, will not (in the
> absence of memory corruption or bad casts) mistakenly treat the ``v_type''
> field of a struct vnode as anything but a of type ``enum vtype'', the Lisp will
> correctly, reliably treat the bits of a value which represent its type.
>
> If the given Lisp system encodes some type information in the top three bits of
> the word representing a value, then by golly, all of its operations will
> reliably store and retrieve that type information in those top three bits.
>
> So you see there is the same kind of low-level static typing going on in Lisp,
> and similar languages, just under the hood.
>
> The programmer-visible types in Lisp are a higher level concept, because it's a
> higher level language. They are simply an additional kind of domain value
> attributed to an object. They are not like type in a static language, even
> though they express the same concept in simple-minded programs which
> ipmlement a design that is also directly implementable in a static language.
>
> Dynamic typing allows an entire class maintainable, clear, useful program
> /designs/ to be coded in the obvious, straightforward way, and safely executed
> in the presence of run-time checks.
>
> Static typing which rejects the straightforward implementation of these designs
> nevertheless allows the programmer to implement these designs in a different
> way, one which is not so straightforward, and not well supported (or at all) in
> the language. Not only can this be done, but it is regular practice.
>
> > I'm not sure about Common Lisp, but in Scheme ...
>
> Trolling asshole, since you're sending articles to comp.lang.lisp rather than
> comp.lang.scheme, maybe you should take a few steps to become sure.

Scheme is Lisp.

Vend wrote:
> On 28 Ago, 23:54, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Vend <ven...@virgilio.it> writes:
>>> On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
>>> wrote:
>>>> DeverLite <derby.lit...@gmail.com> writes:
>>>>> [...] Although very flexible, and good at catching errors at compile
>>>>> time, I found the typing system in Haskell sometimes got in the way.
>>>>> Lisp let's you declare types, but if you don't want to you don't have
>>>>> to, and this tends to make it more flexible than Haskell.
>>>> Actually, what the lisp type system means is that in lisp we program
>>>> in generic mode by default.
>>>> When you write:
>>>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>>> it's statically typed, but it's also SPECIFICALLY typed.
>>>> When you write in lisp:
>>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>>> it's already a generic function (not a lisp generic function,
>>>> technically, but what other programming languages call a generic
>>>> function):
>>>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>>>> --> (24 24.0 24.0L0 15/8)
>>> But the mathematical factorial function is defined only on natural
>>> numbers, hence this behavior is most likely incorrect.
>> Please, explain how something that is outside of the scope encompassed
>> by a mathematical definition can be "incorrect"?
>
> I said *most likely* incorrect.
>
> That behavior is correct if it's what you want to get, but when
> somebody writes or uses a procedure which calculates the factorial
> function he or she probably means it to be used on natural numbers.

The importance of the factorial function in production code is grossly
overestimated.

>> "Blue" is not defined by the mathmatical factorial function
>> definition. Does that make "blue" incorrect?
>>
>>> Moreover, in dynamically typed languages like Lisp there is the risk
>>> of having a statement like this buried deep in your program:
>>> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
>>> ctrl-alt-shift-tab-right-mouse-button))
>>> (setq bomb "goodbye")
>>> (setq bomb 42))
>>> And then somewhere else a (fact bomb) makes your program crash and
>>> your client angry.
>> But strangely enough, lisp programs crash less often than C and C++
>> programs...
>
> C is statically typed but type-unsafe, among other kind of unsafe
> "features" it has.
> C++ is as unsafe as C and, due to its object orientation model, not
> completely statically typed, but the language doesn't insert any
> runtime dynamical type checks, so this is another source of unsafety.
>
> Java has an OO model similar to that of C++ (but simplified) and it's
> type-safe.
> Runtime type errors can occour when attempting to cast the reference
> of a given class type to a reference typed with one of its subclasses.
> I don't have statistics, but I presume that this happens less
> frequently than type errors in completely dynamically typed languages
> like Lisp or Python.
> (I'm not claiming that Java is better than Lisp or Python, I'm just
> comparing this aspect).

Java is a language that serves as a good reference for illustrating how
static type systems can _introduce_ new sources of bugs which don't
exist in dynamically typed languages:
http://p-cos.net/documents/dynatype.pdf

Whether a type system is dynamic or not doesn't tell you a lot. You need
a _good_ type system. For example, one that gives something close to a
half when you divide one by two, or something that doesn't silently wrap
around when you get beyond 32 bits. Few type systems have these
characteristics.


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

Vend wrote:
> On 28 Ago, 23:43, Pascal Costanza <p...@p-cos.net> wrote:
>> Vend wrote:
>>> On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
>>> wrote:
>>>> DeverLite <derby.lit...@gmail.com> writes:
>>>>> [...] Although very flexible, and good at catching errors at compile
>>>>> time, I found the typing system in Haskell sometimes got in the way.
>>>>> Lisp let's you declare types, but if you don't want to you don't have
>>>>> to, and this tends to make it more flexible than Haskell.
>>>> Actually, what the lisp type system means is that in lisp we program
>>>> in generic mode by default.
>>>> When you write:
>>>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>>> it's statically typed, but it's also SPECIFICALLY typed.
>>>> When you write in lisp:
>>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>>> it's already a generic function (not a lisp generic function,
>>>> technically, but what other programming languages call a generic
>>>> function):
>>>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>>>> --> (24 24.0 24.0L0 15/8)
>>> But the mathematical factorial function is defined only on natural
>>> numbers, hence this behavior is most likely incorrect.
>> Who said that his definition is about the "mathematical factorial function"?
>>
>>> Moreover, in dynamically typed languages like Lisp there is the risk
>>> of having a statement like this buried deep in your program:
>>> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
>>> ctrl-alt-shift-tab-right-mouse-button))
>>> (setq bomb "goodbye")
>>> (setq bomb 42))
>> The risk is very low, unless you have total retards working on your code
>> base.
>>
>> Pascal
>
> My example was specifically written to make the flaw apparent, but are
> you sure that these situations are rare in practice?

What if they are rare: How would you recognize that?

> Have you ever seen a program which manages a collection of objects of
> heterogeneous type, which isn't know at compile-time?

Yep, I use them quite a lot actually.

> Now let's assume there is an operation done infrequently on some
> objects of that collection, which works on all the possible types
> except an infrequently occurring one.
>
> Maybe the guy who wrote that operation wasn't aware of the existence
> of that type, or wasn't thinking about it, or that type was added
> later by someone not aware of the existence and contract of that
> operation. It doesn't seem a very unlikely scenario does it?
>
> Anyway the result will be an infrequent runtime type error which will
> probably escape the testing.

That's all just speculation.

Where do you see the masses of experience reports and anecdotes how such
errors _actually_ screw up software systems?

The most often reported screw up is buffer overruns, which can be
exploited in security attacks. Such overruns are best handled by dynamic
checks.

You see the pattern?


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

On 2008-08-28, Vend <vend82@virgilio.it> wrote:
> Have you ever seen a program which manages a collection of objects of
> heterogeneous type, which isn't know at compile-time?

This is almost the same as asking, ``Have you worked in the software
industry for any period within the last twenty years?''

On Aug 28, 4:13 pm, Vend <ven...@virgilio.it> wrote:
>
> Have you ever seen a program which manages a collection of objects of
> heterogeneous type, which isn't know at compile-time?
>
> Now let's assume there is an operation done infrequently on some
> objects of that collection, which works on all the possible types
> except an infrequently occurring one.

Yes, there are programming errors that can be caught by static type
checking. I don't think anyone is disputing that.

But there are also plenty of errors that cannot be caught by static
typing. Any substantial program these days, even in a statically
typed language, has (or should have) numerous calls to `assert' or the
equivalent, checking preconditions of operations at runtime that
cannot be checked statically. Often, a formal proof that a particular
assertion is not violated would be quite difficult to produce; there
certainly is no static analyzer out there that can generate such
proofs in very many cases.

So although static typing does catch some errors, and can be useful,
it can't catch all of them. Furthermore, the ones it does catch are
those that are relatively easy to find anyway because they primarily
show up as violations of local constraints. Those that require deep
analysis, and particularly those requiring inductive proofs, are out
of its reach.

Static typing advocates want to make this a difference of kind, but
it's really just a difference of degree. With static typing, you
invest more effort up front and accept some limitations on the way you
can write your program, and in exchange the compiler finds some bugs
for you. It's a tradeoff. I'm not even saying it's never a trade
worth making. But in the end you still have to write interface
documentation to (try to) make sure that clients of your interface
don't abuse it.

-- Scott