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

On Jul 12, 11:05 pm, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
Marco Antoniotti wrote:
On Jul 12, 6:03 pm, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
Marco Antoniotti wrote:
On Jul 12, 4:00 pm, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
Don Geddis wrote:
From which it is clearly impossible to decipher a working program. So
your point is obviously wrong. In reality, deliberately miscounting
the number of tokens was just clutching at straws. A desperate attempt
to make Lisp look less stupid.

let val x = 40 + 2.0;;

yielding an error is what I call mildly stupid. :)  After all we all
know the rules about '+' since junior high.

Except those rules do not apply in the context of floating point
arithmetic, e.g. associativity:

# (0.1 +. 0.2) +. 0.3 = 0.1 +. (0.2 +. 0.3);;
- : bool = false

Come on.  You know what I am getting at.

I also know what you're glossing over.

What is the result of:

  1. / 0

is it an integer divide by zero exception or the special floating point
infinity?

In CL it is clearly defined as a raising an exception. I do not know
what MLish languages do in this case. I suppose that you could check
the constant 0 and raise a compiler error.

The static error you describe forces the programmer to clarify the code
before the program can be run. Claiming that to be "mildly stupid" is
mildly stupid. Implying that floats and ints should be interchangeable when
they have wildly different properties is considerably more stupid.

Maybe, but number coercing rules are pretty well understood. It is
true that you get the "debug early" effect, but this at the price of
getting very annoyed with the compiler.




I can write very fast and "type-correct" CL code in implementation X using

    (low-level-stuff::*. 40.0 2.0)

Moreover

CL-USER 40 > (= (+ 1.0 (+ 2.0 3.0)) (+ (+ 1.0 2.0) 3.0)) ; LWM on an
Intel Mac.
T

So: which is "correct"? LWM or Ocaml?

If you are trying to compare my OCaml code with your Lisp translation then
your Lisp translation is wrong.

And why?

Because you used the wrong numbers. Specifically, you used decimals that
happen to have exact representations in machine-precision floating point so
the results happen to be equal for that particular case.

Fine. I was stupid.

CL-USER> (= (+ 0.1 (+ 0.2 0.3)) (+ (+ 0.1 0.2) 0.3))
T

Or isn't this just the the well known "thou shall not compare two floating
point numbers?"

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).



If someone said "Mathematica is better because it bundles interval
arithmetic" then I would be inclined to agree.

And the expert Lisp programmers who invented Dylan, OCaml, SML...

Ahem, Dylan is a relatively good thing, but it is CL down to the
core.  Cleaned up as much as you want, but that is what it is.  And it
may be that is was Java to make Dylan wimper.  Moreover, it has been
accepted that Dylan Big Mistake was to abandon S-expr syntax.

Mathematica abandoned s-exprs and is a resounding success.

Maybe.  Deep, deep down, at least until some time ago, mathematica was
all Conses.  I have not checked it lately.

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. In general I defer my
opinions about Mathematica to people who know better, like Fateman.



So what you're really saying is that people who don't know any better
don't complain. I'd agree with that but it applies just as much to the
tiny lingering Lisp community as it does elsewhere. Observe how
Lispers not only fail to understand the benefits of pattern matching
but are even oblivious to its increasingly widespread use.

I have not seen pattern-matching pop up in Java or C#...

Look at Scala and F#.

Scala is a language on its own as is F#.

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#. I know about
F#. I am playing with it.

I have not played around
with Scala (which looks like a "lets-look-like-C" language), but I
have been playing with F#, which is well integrated within MSVS and it
is nice to use.  But that is a MLish language.

F# is MLish, yes.

You are not seeing pattern matching popping up in Java 7 (is it?).
Same for the next C#.

F# is the next C# and it does have pattern matching.

That is wishful thinking on your part. Of course F# has pattern
matching, but that does not mean that F# is taking over C# or that C#
is getting pattern matching.

Scala is considered to be the next Java by many of its proponents and it
also has pattern matching.

Scala runs on the JVM, but it is a Java extension just much as Clojure
is. Just perusing the Scala manual makes you see that it is not Java.






That is also obviously wrong. The creators of the ML family of
languages embarked on that journey and they not only completed it,
creating a new family of languages without superfluous parentheses,
but the fruits of their labour (OCaml and F#) are now used by more
people than Lisp ever was.

Your last sentence can only be greeted with a "maybe".  As per the
first part, it is mostly true.  Yet, there is *no* way to add new
language features to such languages: any new "language" in the style
of MLish syntax needs a fresh "compiler".  Witness the interesting
PADS/ML work.

That is not true. Look at camlp4, for example. Then look at the F# code
dom. Finally, consider what it takes to create a "fresh compiler" when
the source to the original is available.

Nope.  camlp4 does not count as an argument.  It is a preprocessor
outside the core language.

Camlp4 is a preprocessor (just like Lisp's macros) but it can be used
interactively and it is part of the core OCaml distribution.

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.


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. That would definitively prove the fundamental theorem on
programming languages :) Yet, doing pattern compilation in CL is
simple. Extending CL is simple. The work goes in getting the "look-n-
feel" right. One of the problems I have with your posts is that you
keep confusing pattern matching and type inferencing. These are
separate issues, and I am staying clear of even hinting that I am
going to write a type inferencing engine for CL.


The only way you could possibly have remained oblivious to this is by
burying your head in Lisp and not learning about the alternatives. So
you just made my point. Thank you.

... and telling people who chose to stick to CL (also after having
used ML/Haskellish systems and/or written other languages' compilers
and systems) that they are stupid where is getting you?

Again, you are just proving my point. You are claiming to be familiar
with alternatives whilst simultaneously making false statements about
them and then claiming that Lisp is Blub.

What false statements am I making?

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. I claim that the use of camlp4 is at a different
level than using the CL macro system. Like it or not that is the way
it is. It is the ball of mud vs. the muddy camel argument. :) I am
not saying that a muddy camel is a bad thing. Hey, you can also say
that a camel (muddy or not) moves, and a ball of mud does not. :) I
guess Lisp programmers are just piglets who love rolling in mud :)

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
(which is a good alternative w.r.t. any SLDJ :) )

Cheers
--
Marco


.

Relevant Pages

  • Re: Benefits of Dynamic Typing
    ... >> elegantly and efficiently in many other languages. ... > There are lots of extensions to Lisp to provide pattern matching, ...
    (comp.lang.functional)
  • Re: Benefits of Dynamic Typing
    ... > ML's pattern matching goes far beyond dispatching on types and lists. ... > elegantly and efficiently in many other languages. ... There are lots of extensions to Lisp to provide pattern matching, ... Or even some kind of Description Logics ...
    (comp.lang.functional)
  • Re: Flamebait if I ever saw it
    ... and end-all of programming that you do. ... A lot of early Lisp used to use pattern-matchy constructs, ... having pattern matching, or saying those languages are wrong/bad/whatever. ...
    (comp.lang.lisp)
  • When static typing is worth it
    ... typed languages like Lisp. ... developed more quickly in modern statically typed languages than ... static type system and remove run-time checks. ... incurs a run-time error if the list is ...
    (comp.lang.lisp)
  • Re: What is Lisp used for?
    ... My main languages are Perl, Java, and ColdFusion. ... Lisp PHP FlamingThunder). ...
    (comp.lang.lisp)