Re: SBCL is now faster than Java, as fast as Ocaml, and getting better

Marco Antoniotti wrote:
On Jul 12, 11:05 pm, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
Which is part of my point that Don Geddis' argument that Lisp's integers
make it more suitable for mission critical applications in the specific
context of rockets is completely ridiculous because floats are the source
of far more errors than ints and Lisp is no better than C in that
respect.

Nope. We are talking about different behavior between Ocaml and LWM
(incidentally, I expect other CL implementations to return NIL). As
per the C/CL behavior with ints and floats, they are different and
unrelated. In both cases you have well known pitfalls. In the Ariane
5 disaster, given the very, very strict typing rules of Ada, from what
I gathered from perusing the Google results, there must have been an
Unchecked_Conversion somewhere (I have not seen the code, I am just
surmising).

Arian is irrelevant.

Mathematica is similar to Lisp in many ways but it does use vectors
entirely rather than cons cells. I think the Lisp community have a huge
amount to learn from Mathematica because it addressed so many of Lisp's
deficiencies.

So, Mathematica is no more Conses deep down. As per Lisp deficiencies
w.r.t. Mathematica I think it goes both ways.

What do you think Mathematica can learn from Lisp?

In general I defer my opinions about Mathematica to people who know
better, like Fateman.

Fateman is just another grumpy old Lisper who tried to plagiarise Wolfram's
work, got in trouble with the law for it and then spent the best years of
his life failing to get people to use his free software whilst publishing a
series of petty jabs at Mathematica. His knowledge is now decades out of
date.

I don't know what you mean by "a language on its own" but F# is being
productized by Microsoft and placed along C# and VB as their next
generation language for .NET.

I mean that it is not an extension of Java or C++ or C#.

Yes, of course.

So OCaml is actually every bit as extensible as Lisp and, of course, many
people have published extensions for it. For example, Martin Jambon has
extended OCaml's ordinary pattern matching to also support regular
expression matching, by writing a camlp4 syntax extension:

http://martin.jambon.free.fr/micmatch-howto.html

Nope. It still does not count. Of course you can do very neat things
with camlp4, but it just isn't the same as the macro system plus the
code-is-data of (any) Lisp.

Perhaps we can get to the root of your misconception: what exactly do you
mean by "just isn't the same" given that they have the same capabilities?

I do not know F# dom, but I would be surprised if it were different.

Put it this way.  Get me away from actual work and saturday afternoons
writing on CLL :) and I will get you an extended CL written *in* CL
that did pattern matching (avec pattern compilatiòn).

You are grossly underestimating the effort required to Greenspun modern
language features.

I specifically did not talk about writing a full blown type-inferencer
for CL.

Neither was I.

That would definitively prove the fundamental theorem on
programming languages :) Yet, doing pattern compilation in CL is
simple.

You are grossly underestimating the effort required to Greenspun a modern
pattern matcher.

Extending CL is simple.

Not if the extension is inherently complicated, as pattern matching is.

One of the problems I have with your posts is that you keep confusing
pattern matching and type inferencing.

I have said nothing of type inference. I am telling you that implementing a
modern pattern matcher is far harder than you apparently think.

These are separate issues, and I am staying clear of even hinting that I
am going to write a type inferencing engine for CL.

This never had anything to do with type inference.

Every single statement you have made about OCaml's extensibility has been
completely wrong. You appear to have read and misunderstood the Wikipedia
page without actually trying to find how people have already used camlp4
to do all of the things that you are claiming to be impossible.

I claim something very precise and very different from what you are
attributing me.

You claims are anything but precise. Look:

I claim that the use of camlp4 is at a different level than using the CL
macro system.

See. What is "at a different level" supposed to mean?

Like it or not that is the way it is.

Now you're asserting a meaningless statement as a fact.

Again, you are proving my point about Lispers. You should get out there
and learn more about modern languages by actually using them. Once you
know the facts you will be able to substantiate your arguments but, of
course, if you knew the truth you would not be using Lisp...

If I remember correctly, I wrote a type inferencer in ML well before
you appeared in C.L.L.; actually it was a translation of Miranda
code. *And* I am playing with F# (and Haskell). I think I am looking
around quite a bit; some things I like, other I like less. I don't
program much anymore, and, BTW, most code I see these days is Java

Then I fully understand why you've stopped coding.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
.

Relevant Pages

  • Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
    ... amount to learn from Mathematica because it addressed so many of Lisp's ... What do you think Mathematica can learn from Lisp? ... are overestimating the "language merits" of Mathematica as far as its ... go beyond our discussion of Lisp, MLish and pattern matching. ...
    (comp.lang.lisp)
  • Re: Lisp and Scheme with fewer parentheses / Mathematica??
    ... programing in Mathematica is like in sense a glorified ... macros system as used in lisp. ... in Mathematica, ... You might not be able to get far using pattern matching alone but you can ...
    (comp.lang.lisp)
  • Re: Benefits of Dynamic Typing
    ... I would say that Lisp has been displaced by faster languages ... I am still trying to find any applications where Lisp can ... From your point of view and experience Mathematica might ... > Yet when they want pattern matching they use an ad hoc informally-specified ...
    (comp.lang.functional)
  • Re: merits of Lisp vs Python
    ... many other interesting features that haven't originated from Lisp (e.g. ...
    (comp.lang.lisp)
  • Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
    ... what MLish languages do in this case. ... If you are trying to compare my OCaml code with your Lisp translation then ... Lispers not only fail to understand the benefits of pattern matching ... but it is a Java extension just much as Clojure ...
    (comp.lang.lisp)