Wow, pattern matching is EASY in Lisp! It's like you can write
your own language. It's almost hard to believe a language can be
as powerful and flexible as Lisp. This ML-style pattern matcher
takes just a few hours to write, even less for a real Lisp guru.
The implementation is only a couple dozen lines of code, and it
does the basics of pattern matching that has to be built-in in
other languages. Lisp is a truly remarkable language.
Here's some client code that uses MATCH:
> (defun print-patrn (patrn)
> (match patrn
> ( :nil (format t "~A is null.~%" patrn))
> ((:list a b c ) (format t "~A is a triple of ~A, ~A, and ~A.~%"
> patrn a b c))
> ((:cons head tail) (format t "~A is a cons of ~A and ~A.~%"
> patrn head tail))
> ( :t (format t "~A is something else.~%" patrn))))
>
> (print-patrn nil)
> (print-patrn '(a e i o u))
> (print-patrn '(1 2 3))
> (print-patrn 10)
> (print-patrn "Fooberry")
Here's the output:
> NIL is null.
> (A E I O U) is a cons of A and (E I O U).
> (1 2 3) is a triple of 1, 2, and 3.
> 10 is something else.
> Fooberry is something else.
And here's the implementation. It's amazing how easy
Lisp's macros and s-expressions make it:
> (defmacro match (patrn &rest in-clauses)
> (let ((val (gensym "MATCH-VAL"))
> (out-clauses '()))
> (dolist (in-clause in-clauses)
> (let* ((patrn (car in-clause))
> (code (cdr in-clause))
> (out-clause
> (if (atom patrn)
> (case patrn
> (:t `( t ,@code))
> (:nil `((not ,val) ,@code)))
> (let ((type (car patrn))
> (vars (cdr patrn)))
> (case type
> (:cons `((consp ,val)
> (let ((,(car vars) (car ,val))
> (,(cadr vars) (cdr ,val))) ,@code)))
> (:list
> (let ((num-vars (length vars))
> (bindings '()))
> (dotimes (n num-vars)
> (push `(,(nth n vars) (nth ,n ,val)) bindings))
> `((and (listp ,val)
> (= (length ,val)
> ,num-vars)) (let ,bindings ,@code)))))))))
> (push out-clause out-clauses)))
> `(let ((,val ,patrn)) (cond ,@(nreverse out-clauses)))))
--
Dan
www.prairienet.org/~dsb/
On 29 Jun, 15:02, Dan Bensen <··········@cyberspace.net> wrote:
> Wow, pattern matching is EASY in Lisp! It's like you can write
> your own language. It's almost hard to believe a language can be
> as powerful and flexible as Lisp. This ML-style pattern matcher
> takes just a few hours to write, even less for a real Lisp guru.
> The implementation is only a couple dozen lines of code, and it
> does the basics of pattern matching that has to be built-in in
> other languages. Lisp is a truly remarkable language.
>
Obviously you haven't read Dijkstra's PATTERN MATCHING considered
harmful.
>From the highlights:
The Occasion of which Insufferable Disaster, after a furious Enquiry,
and Discussion of the Point by the Learned of the Faculty, we can
Attribute to nothing more than the Excessive use of that Newfangled,
Abominable, Heathenish coding style called PATTERN MATCHING, which
Riffling Nature of her Choicest Treasures, and Drying up the Radical
Moisture, has so Eunucht our Husbands, and Cripple our more kind
Gallants, that they are become as Impotent as Age, and as unfruitful
as those Desarts whence that unhappy Berry is said to be brought.
For the continual flipping of this pitiful notation is enough to
bewitch Men of two and twenty, and tie up the Codpiece-points without
a Charm. It renders them that us it as Lean as Famine, as Rivvel'd as
Envy, or an old meager Hagg over-ridden by an Incubus. They come from
it with nothing moist but their snotty Noses, nothing stiffe but their
Joints, nor standing but their Ears: They pretend 'twill keep them
Waking, but we find by scurvy Experience, they sleep quietly enough
after it. A Betrothed Queen might trust her self a bed with one of
them, without the nice Caution of a sword between them: nor can call
all the Art we use revive them from this Lethargy, so unfit they are
for Action, that like young Train-band-men when called upon Duty,
their Ammunition is wanting; peradventure they Present, but cannot
give Fire, or at least do but flash in the Pan, instead of doing
executions.
Chris Russell wrote:
> Obviously you haven't read Dijkstra's PATTERN MATCHING considered
> harmful.
>
>>From the highlights:
[ lots of flaming ]
English is not my native language, so maybe I'm missing something, but is
there some objective critic about pattern matching in this flaming or is
Dijkstra just jealous that he doesn't invented pattern matching?
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 29 Jun, 15:45, Frank Buss <····@frank-buss.de> wrote:
> Chris Russell wrote:
> > Obviously you haven't read Dijkstra's PATTERN MATCHING considered
> > harmful.
>
> >>From the highlights:
>
> [ lots of flaming ]
>
> English is not my native language, so maybe I'm missing something, but is
> there some objective critic about pattern matching in this flaming or is
> Dijkstra just jealous that he doesn't invented pattern matching?
>
> --
> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
Ahh, sorry.
It's not a Dijkstra's quote it's actually taken from a 17th century
polemic against the drinking of coffee.
The title of this thread intentionally parodies Harop's thread
Unlearning Lisp, where he rips of another Dijstra quote about:
"It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers they
are mentally mutilated beyond hope of regeneration."
http://www.cs.virginia.edu/~evans/cs655-S00/readings/ewd498.html
and pretends that he's talking about lisp.
I thought the archaic style would warn people that it's not actually a
quote by Dijstra, but I forgot about the non-English speakers.
Sorry again.
On 2007-06-29, Chris Russell <·····················@gmail.com> wrote:
> I thought the archaic style would warn people that it's not actually
> a quote by Dijstra, but I forgot about the non-English speakers.
Regardless, I thought it was hilarious. Thanks for posting.
On Jun 29, 9:45 am, Frank Buss <····@frank-buss.de> wrote:
> Chris Russell wrote:
> > Obviously you haven't read Dijkstra's PATTERN MATCHING considered
> > harmful.
>
> >>From the highlights:
>
> [ lots of flaming ]
>
> English is not my native language, so maybe I'm missing something, but is
> there some objective critic about pattern matching in this flaming or is
> Dijkstra just jealous that he doesn't invented pattern matching?
I use pattern matching extensively in Erlang and OCaml, and love it in
both. It makes the code readable and very terse. I don't believe the
follow-up was a flame, and I did find it funny to read (I personally
swapped out "PATTERN MATCHING" for "C++" for a good laugh).
My understanding of pattern matching and Common Lisp, though, was that
it was attempted and it was very difficult to come up with something
non-insane that fit the needs of everyone that wanted it. And, that
Lisp itself was powerful enough for anyone to implement what *they*
needed on their own rather quickly, so why bother adding it to an
already complex standard.
Of course, I'm young still, and haven't been using Lisp for a long
time, so the above is just what I've gathered from other ng postings
here over time. And perhaps skewed from a bad memory.
Jeff M.
On Jun 29, 5:16 pm, "Jeff M." <·······@gmail.com> wrote:
> I use pattern matching extensively in Erlang and OCaml, and love it in
> both. It makes the code readable and very terse. I don't believe the
> follow-up was a flame, and I did find it funny to read (I personally
> swapped out "PATTERN MATCHING" for "C++" for a good laugh).
>
> My understanding of pattern matching and Common Lisp, though, was that
> it was attempted and it was very difficult to come up with something
> non-insane that fit the needs of everyone that wanted it. And, that
> Lisp itself was powerful enough for anyone to implement what *they*
> needed on their own rather quickly, so why bother adding it to an
> already complex standard.
My experience with pattern matching in SML has been very pleasant,
although I've never worked on large systems in ML, and certainly not
in an industrial environment. One problem with pattern matching/
unification systems in CL is that they have a tendency to break
encapsulation. You can of course easily build a pattern-matching
system that obeys the appropriate encapsulation rules for a certain
project, and they're easy and effective. The general problem of
pattern matching in the presence of a real object system seems a lot
harder, though. I haven't looked at OCaml's object system, but being
statically typed, I can't imagine it counts as a "real" object system
(I say as a Lisper and Smalltalker). And, all things being equal,
I'll take my FP support along side a message-passy dynamic object
system rather than along side a simple unification engine. Most of
the time, at least. And we always have CL-Prolog integration for the
remaining cases :-)
> Of course, I'm young still, and haven't been using Lisp for a long
> time, so the above is just what I've gathered from other ng postings
> here over time. And perhaps skewed from a bad memory.
In terms of pattern matching, I think the Lisp community has
historically been looking in the direction of Prolog-style unification
rather than ML's cute dispatching hack. And we have plenty of
libraries that span the range from a-little-prolog-with-your-lisp to
full-blown optimized prolog implementations in Lisp (mmm, Allegro).
On 2007-06-29, Thomas F. Burdick <········@gmail.com> wrote:
>> Of course, I'm young still, and haven't been using Lisp for a long
>> time, so the above is just what I've gathered from other ng
>> postings here over time. And perhaps skewed from a bad memory.
>
> In terms of pattern matching, I think the Lisp community has
> historically been looking in the direction of Prolog-style
> unification rather than ML's cute dispatching hack. And we have
> plenty of libraries that span the range from
> a-little-prolog-with-your-lisp to full-blown optimized prolog
> implementations in Lisp (mmm, Allegro).
I've often wondered why more Lispers don't do more with unification,
or promote it more. I haven't played with unification much, but I
have played with regular expressions *a lot*, and unification seems
more powerful, though it is more verbose (in the forms in which I've
seen it).
-- L
Dan Bensen wrote:
> This ML-style pattern matcher takes just a few hours to write...
A good educational exercise but Greenspun.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop wrote:
> A good educational exercise but Greenspun.
Nah. A couple dozen lines doesn't count as Greenspunning.
Lisp's macro system is so powerful, it just doesn't make sense
to fret over whether a pattern-matching system is built-in
or custom-made. Given enough interest, a pattern matcher
can eventually be standardized and included in popular
implementations, just like LOOP and CLOS. Thanks for
introducing the challenge, though. It was fun. :)
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> Jon Harrop wrote:
>> A good educational exercise but Greenspun.
>
> Nah. A couple dozen lines doesn't count as Greenspunning.
If you could write a decent implementation in a couple of dozen lines I
would agree. However, a decent pattern matcher is thousands of lines of
code.
Just the exhaustiveness and redundancy testing part of OCaml's pattern
matcher is 1,700 lines long, and it would be a lot longer were it not
written using pattern matching...
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop wrote:
>>> A good educational exercise but Greenspun.
>> Nah. A couple dozen lines doesn't count as Greenspunning.
> Just the exhaustiveness and redundancy testing part of OCaml's pattern
> matcher is 1,700 lines long, and it would be a lot longer were it not
> written using pattern matching...
So is OCaml Greenspunned?
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> Jon Harrop wrote:
>>>> A good educational exercise but Greenspun.
>>> Nah. A couple dozen lines doesn't count as Greenspunning.
>> Just the exhaustiveness and redundancy testing part of OCaml's pattern
>> matcher is 1,700 lines long, and it would be a lot longer were it not
>> written using pattern matching...
>
> So is OCaml Greenspunned?
The authors invented part of the algorithm, so I'd say not.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
(message (Hello 'Jon)
(you :wrote :on '(Sat, 30 Jun 2007 08:07:27 +0100))
(
JH> The authors invented part of the algorithm, so I'd say not.
have they pattented it? or something else prevents from porting that
algorithm to other languages?
Greenspunning is when you emulate something, but not when you _integrate_
something. think about this.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"scorn")
Alex Mizrahi wrote:
> JH> The authors invented part of the algorithm, so I'd say not.
>
> have they pattented it? or something else prevents from porting that
> algorithm to other languages?
They even describe it in academic papers and you are free to reimplement it.
> Greenspunning is when you emulate something, but not when you _integrate_
> something. think about this.
Yes.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop schrieb:
> Dan Bensen wrote:
>> This ML-style pattern matcher takes just a few hours to write...
>
> A good educational exercise but Greenspun.
Why is it Greenspun?
On Sat, 30 Jun 2007 02:21:47 +0200, Andr� Thieme
<······························@justmail.de> wrote:
>Jon Harrop schrieb:
>> Dan Bensen wrote:
>>> This ML-style pattern matcher takes just a few hours to write...
>>
>> A good educational exercise but Greenspun.
>
>Why is it Greenspun?
Because Harrop doesn't like it.
--
for email reply remove "/" from address
On Sat, 30 Jun 2007 02:21:47 +0200, =?ISO-8859-1?Q?Andr=E9_Thieme?=
<······························@justmail.de> tried to confuse everyone with this
message:
>Jon Harrop schrieb:
>> Dan Bensen wrote:
>>> This ML-style pattern matcher takes just a few hours to write...
>>
>> A good educational exercise but Greenspun.
>
>Why is it Greenspun?
Because it also contains fully functional Common Lisp implementation!
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> Dan Bensen wrote:
>>> This ML-style pattern matcher takes just a few hours to write...
>>
>> A good educational exercise but Greenspun.
>
> Why is it Greenspun?
He is reimplementing half of a modern FPL (the pattern matcher). The
implementation is ad-hoc (not even a feature list) and if it took a few
hours then he most likely didn't read any of the research that has been
done in this area. There is no specification. The implementation doesn't
affect the compiler's optimizer, so it will be comparatively slow.
So we have:
ad-hoc
informally-specified
bug-ridden
slow
reimplementation of half of OCaml/SML/Haskell/F#/Scala/.
The pattern matchers in these languages are well-specified, mature and fast.
So lashing together something that looks similar is classic Greenspun. That
doesn't stop it from being a good educational exercise, of course, but the
proof is in the pudding so Dan might like to benchmark his implementation
against some of the major players.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
On 30 jun, 10:14, Jon Harrop <····@ffconsultancy.com> wrote:
> Andr� Thieme wrote:
> > Jon Harrop schrieb:
> >> Dan Bensen wrote:
> >>> This ML-style pattern matcher takes just a few hours to write...
>
> >> A good educational exercise but Greenspun.
>
> > Why is it Greenspun?
>
> He is reimplementing half of a modern FPL (the pattern matcher). The
> implementation is ad-hoc (not even a feature list) and if it took a few
> hours then he most likely didn't read any of the research that has been
> done in this area. There is no specification. The implementation doesn't
> affect the compiler's optimizer, so it will be comparatively slow.
>
> So we have:
>
> ad-hoc
> informally-specified
> bug-ridden
> slow
>
> reimplementation of half of OCaml/SML/Haskell/F#/Scala/.
>
> The pattern matchers in these languages are well-specified, mature and fast.
> So lashing together something that looks similar is classic Greenspun. That
> doesn't stop it from being a good educational exercise, of course, but the
> proof is in the pudding so Dan might like to benchmark his implementation
> against some of the major players.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The OCaml Journalhttp://www.ffconsultancy.com/products/ocaml_journal/?usenet
The book "Lisp in small pieces" LISP
of C.Queinnec give some good examples of pattern-matching and
filtering and
construct an interface for a natural robot language.
The examples are in lisp but not common lisp.
http://www-spi.lip6.fr/~queinnec/WWW/LiSP.html
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> Jon Harrop schrieb:
>>> Dan Bensen wrote:
>>>> This ML-style pattern matcher takes just a few hours to write...
>>> A good educational exercise but Greenspun.
>> Why is it Greenspun?
>
> He is reimplementing half of a modern FPL (the pattern matcher).
In what programming language do you suppose was the first PM written?
Why did other languages greenspunned it?
Or remember the GC. I think OCaml has also one. Why implement one in
OCaml when it already was available in Lisp?
I mean, PM is nothing but syntactic sugar. Lisp already is a FPL.
By adding a way to express things a bit shorter and with more syntax in
Lisp does not affect it beeing a FPL or a more modern one.
> The implementation doesn't
> affect the compiler's optimizer, so it will be comparatively slow.
Well, PM code in the end expands into a bunch of IFs under the hood.
It might not be the fastest PM, but the point is to write programs in a
shorter amount of time and make parts of them more readable.
With some more work on it one could probably improve its execution speed.
Andr� Thieme wrote:
> In what programming language do you suppose was the first PM written?
> Why did other languages greenspunned it?
>
> Or remember the GC. I think OCaml has also one. Why implement one in
> OCaml when it already was available in Lisp?
Greenspun is about users having to rewrite common code because the language
doesn't bundle it.
> PM is nothing but syntactic sugar.
Syntactic sugar doesn't do static verification and algorithmic optimization.
> By adding a way to express things a bit shorter and with more syntax in
> Lisp does not affect it beeing a FPL or a more modern one.
Common Lisp lacks modern features.
> Well, PM code in the end expands into a bunch of IFs under the hood.
Sometimes, yes.
> It might not be the fastest PM, but the point is to write programs in a
> shorter amount of time and make parts of them more readable.
> With some more work on it one could probably improve its execution speed.
If you work at that really hard for 30 years you'll end up with OCaml.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
On Jul 1, 3:10 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Greenspun is about users having to rewrite common code because the language
> doesn't bundle it.
Really? I was always under impression that Greenspun's rule is about
users needing one feature
from a language, but having to implement the whole language because
that feature heavily
depends on basics of that language (like dynamic typing, code as data
etc)
······@gmail.com wrote:
> On Jul 1, 3:10 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> Greenspun is about users having to rewrite common code because the
>> language doesn't bundle it.
> Really? I was always under impression that Greenspun's rule is about
> users needing one feature
> from a language, but having to implement the whole language because
> that feature heavily
> depends on basics of that language (like dynamic typing, code as data
> etc)
I think it was originally poking fun at the fact that almost all C programs
contain an implementation of the list data structure and many contain a
poor garbage collector. You're obviously much better off writing in a
language that has built-in support for lists and a GC (e.g. Lisp).
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop wrote:
> ······@gmail.com wrote:
>> On Jul 1, 3:10 am, Jon Harrop <····@ffconsultancy.com> wrote:
>>> Greenspun is about users having to rewrite common code because the
>>> language doesn't bundle it.
>> Really? I was always under impression that Greenspun's rule is about
>> users needing one feature
>> from a language, but having to implement the whole language because
>> that feature heavily
>> depends on basics of that language (like dynamic typing, code as data
>> etc)
>
> I think it was originally poking fun at the fact that almost all C programs
> contain an implementation of the list data structure and many contain a
> poor garbage collector. You're obviously much better off writing in a
> language that has built-in support for lists and a GC (e.g. Lisp).
Lists and garbage collection is just a fraction of what Common Lisp
provides, not even remotely close to "half of Common Lisp."
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/
Pascal Costanza wrote:
> Lists and garbage collection is just a fraction of what Common Lisp
> provides, not even remotely close to "half of Common Lisp."
Sure, but most C programs don't implement the rest of Lisp (numeric tower,
dynamic typing, macros, s-exprs...).
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop wrote:
> Andr� Thieme wrote:
[...]
>> It might not be the fastest PM, but the point is to write programs in a
>> shorter amount of time and make parts of them more readable.
>> With some more work on it one could probably improve its execution speed.
>
> If you work at that really hard for 30 years you'll end up with OCaml.
>
I don't think so. This IMHO is a very silly statement.
OCaml took the static typing route, and lisp took the dynamic typing
route. This induces different syntaxes, different problems, different
goals. We all know here that the debate about static vs dynamic typing
is pointless, it's obvious they both have strong and weak points.
I think lisp will remain dynamically typed. I had a look at Qi and find
it is a very nice language. But I believe you need a richer syntax for
static languages. Also i believe static typing and pattern matching fit
well together [1]. Lisp has taken the other route, so no, lisp will
never become OCaml.
Anyways i don't see what's all the fuss about OCaml. If you want to go
the statically typed route, you should go for the real thing and learn
Haskell. You'll get the best multiprocessing around, the best type
inference, purity, practicality and a nice community as a bonus.
If you want speed, go for C or assembler, if you want static go for
haskell, if you want fame and women, go for lisp.
Sacha
[1] That's my opinion anyways.
Sacha wrote:
> I don't think so. This IMHO is a very silly statement.
>
> OCaml took the static typing route, and lisp took the dynamic typing
> route. This induces different syntaxes, different problems, different
> goals. We all know here that the debate about static vs dynamic typing
> is pointless, it's obvious they both have strong and weak points.
>
> I think lisp will remain dynamically typed. I had a look at Qi and find
> it is a very nice language. But I believe you need a richer syntax for
> static languages. Also i believe static typing and pattern matching fit
> well together [1].
I agree.
> Anyways i don't see what's all the fuss about OCaml. If you want to go
> the statically typed route, you should go for the real thing and learn
> Haskell.
Haskell took the lazy route.
> You'll get the best multiprocessing around, the best type inference,
Type inference is undecidable in Haskell. Memory usage is unpredictable in
Haskell.
> If you want speed, go for C or assembler, if you want static go for
> haskell, if you want fame and women, go for lisp.
I don't think so. This IMHO is a very silly statement.
Women require inference, so Lisp clearly took the celibate route...
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
> Sacha wrote:
>> If you want speed, go for C or assembler, if you want static go for
>> haskell, if you want fame and women, go for lisp.
Jon Harrop wrote:
> Women require inference, so Lisp clearly took the celibate route...
At runtime, Jon, not compile-time. Women require dynamic flexibility.
And they dig the alien.
http://www.lisperati.com/logo.html
:)
--
Dan
www.prairienet.org/~dsb/
Jon Harrop wrote:
> Sacha wrote:
>
>> If you want speed, go for C or assembler, if you want static go for
>> haskell, if you want fame and women, go for lisp.
>
> I don't think so. This IMHO is a very silly statement.
>
> Women require inference, so Lisp clearly took the celibate route...
>
Haha I guess you won this point.
Sacha
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> In what programming language do you suppose was the first PM written?
>> Why did other languages greenspunned it?
>>
>> PM is nothing but syntactic sugar.
>
> Syntactic sugar doesn't do static verification and algorithmic optimization.
The debate static typing vs dynamic typing has to occur every now and then
I guess, and perhaps this is good.
In my opinion static typing is a waste of time.
It only catches a very small amount of errors that I will also find in,
for exmaple, Lisp. But it trades that for a huge impact on productivity.
I trade these 8% longer debugging times for a 450% shorter development time.
Besides that every static type system will have to do dynamic type
checking at program runtime, because only then all information is
available. If you expect a user to enter his/her age, then at some point
you need to make sure that he/she is only allowed to enter digits, or
test his entries, etc.
Also Lisp offers the most advanced static typing system, in the form of
Qi.
How easy is it in OCaml to define a type "prime number" and declare the
function primeAdd to take two of these and then have in your code something
like primeAdd(10, 28) and get a compiler error, because you did not
put in primes as arguments?
So, when you want to do static type checking you better use Lisp for
that, because it catches even more errors at compile time.
So the main argument for STC will lead you to Lisp anyways.
And of course don't forget: in Lisp you can always run more complex code
and test it during its emergence. In a statically typed language the
compiler would refuse to generate a program, which makes testing harder
and results in code with low quality and lots of bugs. On top of that
people think after writing 13 lines of code that compiled, that these
don't have any problem, because the compiler found not warnings/errors.
Also it would be completely inacceptable to go back to the edit/compile/
run cycle, like it was in the 70ies.
>> By adding a way to express things a bit shorter and with more syntax in
>> Lisp does not affect it beeing a FPL or a more modern one.
>
> Common Lisp lacks modern features.
The language standard yes, but the implementations not. And the good
thing here is, that the real world isn't lacking modern programs,
written in Lisp. Sure, would be nice to have them in standard, and if
you have a spare 4 mio. dollars think about invensting them for a new
version of the standard :-)
>> It might not be the fastest PM, but the point is to write programs in a
>> shorter amount of time and make parts of them more readable.
>> With some more work on it one could probably improve its execution speed.
>
> If you work at that really hard for 30 years you'll end up with OCaml.
In what language were the original ML and OCaml compilers written in?
Did it really take the authors 30 man years?
Andr� Thieme wrote:
> The debate static typing vs dynamic typing has to occur every now and then
> I guess, and perhaps this is good.
Yes.
> In my opinion static typing is a waste of time.
Because Lisp polluted your mind.
> It only catches a very small amount of errors
Then you were not writing your statically-typed code well. This is exactly
what I was referring to when I cited "Speed comparison: PLT Scheme, Ocaml
and C++" by Ian O. He wrote:
let valid_board b =
match b with
Some (Board (_, _)) -> true
| _ -> false;;
which is literally implementing dynamic typing, undermining static typing,
bloating the code and slowing it down. If you write in this style then you
will conclude "static typing only catches a very small amount of errors".
> that I will also find in,
> for exmaple, Lisp. But it trades that for a huge impact on productivity.
I would love to see an example of dynamic typing being more productive (say,
faster or more concise).
> I trade these 8% longer debugging times for a 450% shorter development
> time.
I think this is very domain specific. Whenever you have large amounts of
self-contained code, static checking will be effective. If you are writing
lots of small, independent programs then static checking will be much less
useful.
> Besides that every static type system will have to do dynamic type
> checking at program runtime, because only then all information is
> available. If you expect a user to enter his/her age, then at some point
> you need to make sure that he/she is only allowed to enter digits, or
> test his entries, etc.
This is solved the same way that it is in dynamic languages, with no
significant overhead.
> Also Lisp offers the most advanced static typing system, in the form of
> Qi.
Can you be more specific? What does Qi offer than OCaml and Haskell don't,
for example?
> How easy is it in OCaml to define a type "prime number" and declare the
> function primeAdd to take two of these and then have in your code
> something like primeAdd(10, 28) and get a compiler error, because you did
> not put in primes as arguments?
OCaml's type system cannot statically enforce primality, so you would resort
to run-time tests and maybe tag the int as being prime.
> So, when you want to do static type checking you better use Lisp for
> that, because it catches even more errors at compile time.
> So the main argument for STC will lead you to Lisp anyways.
Illogical. Why Lisp?
> And of course don't forget: in Lisp you can always run more complex code
> and test it during its emergence. In a statically typed language the
> compiler would refuse to generate a program, which makes testing harder
It tends to make testing pointless.
> and results in code with low quality and lots of bugs.
Most people have found otherwise.
> On top of that
> people think after writing 13 lines of code that compiled, that these
> don't have any problem, because the compiler found not warnings/errors.
People write 1,000 lines of statically typed code and, once it is compiled,
they find that unit tests pick up zero errors and the code turns out to be
flawless. I have found this many times.
> Also it would be completely inacceptable to go back to the edit/compile/
> run cycle, like it was in the 70ies.
Then use the REPLs.
> The language standard yes, but the implementations not.
Try to find a decent Lisp pattern matcher, for example.
> And the good thing here is, that the real world isn't lacking modern
> programs, written in Lisp.
There is no competition from the Lisp world in what we do.
> Sure, would be nice to have them in standard, and if
> you have a spare 4 mio. dollars think about invensting them for a new
> version of the standard :-)
Lots of people here now agree that pattern matching is useful. It would be
nice to have a decent pattern matcher in Lisp, preferably a good standard
one that is bundled but a defacto-standard library would be almost as good.
Lots of people have said they will write one over the past few years. Still
nobody has.
> In what language were the original ML and OCaml compilers written in?
Early ML and CAML implementations were written in Lisp and their compilers
were then bootstrapped to target a Lisp VM:
http://caml.inria.fr/about/history.en.html
http://www.pps.jussieu.fr/~cousinea/Caml/caml_history.html
Then everything was customized to support features and optimizations that
could not be added to Lisp because they rely upon static typing. This
forked the languages and the ML family evolved in a different direction.
Indeed, one could argue that the Lisp language has not evolved since (what
revolutionary features did Common Lisp add?).
> Did it really take the authors 30 man years?
It really took thousands of man-years because there were dozens of
researchers working on it for decades.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> In my opinion static typing is a waste of time.
>
> Because Lisp polluted your mind.
I freed my mind. I came to my conclusions before I started with Lisp.
>> It only catches a very small amount of errors
>
> Then you were not writing your statically-typed code well.
Oh sorry, maybe I wasn't clear enough.
Real world programs (they usually have not soo much to do with Research
and Mathematica) often just don't do what they are supposed to do.
Some errors are typing errors, some are type errors, but most of them
are wrong algorithms. Forgetting cases, not beeing flexible enough, etc.
>> that I will also find in,
>> for exmaple, Lisp. But it trades that for a huge impact on productivity.
>
> I would love to see an example of dynamic typing being more productive (say,
> faster or more concise).
If this is true, I mean, if you really would love that, then start coding
in Lisp. You will see that you run functions when they are not finished.
You see how you change them in the running program. You can do small
changes, just to see if your project benefits from going into that
direction. This all must sound very mysterious to you, because you can't
do that in your statically typed language that is also limited to the
unmodern edit/compile/run cycle.
Just try out Lisp. I read that it was suggested before.
> Besides that every static type system will have to do dynamic type
>> checking at program runtime, because only then all information is
>> available. If you expect a user to enter his/her age, then at some point
>> you need to make sure that he/she is only allowed to enter digits, or
>> test his entries, etc.
>
> This is solved the same way that it is in dynamic languages, with no
> significant overhead.
Exactly, that is my point. A program becomes complex, when it has to
work with a lot of data that is not known well enough during the time of
writing the program.
If I just work on some mathematical stuff then the problem domain is
well specified - I can then work with a statically typed language.
For real world programs this is just a small part of the story. You will
have to do a run time analysis of the data anyway. But if you then have
a system that is more dynamic you profit from that. If you would just
try it out you would see it. But you will probably be working on some
mathentical stuff, mostly interesting for academic uses where you simply
don't experience enough disadvantages of using a statically typed system
to try out something else.
This means you will stay with your feeling that says: "Yes, Lisp is so
damn interesting, that's why I can't leave my fingers from it".
>> Also Lisp offers the most advanced static typing system, in the form of
>> Qi.
>
> Can you be more specific? What does Qi offer than OCaml and Haskell don't,
> for example?
See http://www.lambdassociates.org/
>> How easy is it in OCaml to define a type "prime number" and declare the
>> function primeAdd to take two of these and then have in your code
>> something like primeAdd(10, 28) and get a compiler error, because you did
>> not put in primes as arguments?
>
> OCaml's type system cannot statically enforce primality, so you would resort
> to run-time tests and maybe tag the int as being prime.
In Lisp you can test this during compile time, easily for example by
using Qi.
>> So, when you want to do static type checking you better use Lisp for
>> that, because it catches even more errors at compile time.
>> So the main argument for STC will lead you to Lisp anyways.
>
> Illogical. Why Lisp?
Because it has the most powerful type system, see Qi.
>> And of course don't forget: in Lisp you can always run more complex code
>> and test it during its emergence. In a statically typed language the
>> compiler would refuse to generate a program, which makes testing harder
>
> It tends to make testing pointless.
This is not correct. Just think about the OCaml compiler. There were more
than zero bugs that had to be fixed since the first version, and that
although the code compiled.
But I want to come a bit into your direction:
test driven development makes much less sense for functional style code
that it makes for imperative style code.
I need to test my functional style code as well, but if it works there
is no need to run tests again.
So when you write in a FPL and do your tests you can be very certain
that these parts will work well. But you will have to run tests anyway.
>> and results in code with low quality and lots of bugs.
>
> Most people have found otherwise.
Most people are bad programmers.
But of the best programmers in the world most people agree with my point.
>> On top of that
>> people think after writing 13 lines of code that compiled, that these
>> don't have any problem, because the compiler found not warnings/errors.
>
> People write 1,000 lines of statically typed code and, once it is compiled,
> they find that unit tests pick up zero errors and the code turns out to be
> flawless. I have found this many times.
Things would change when you begin to write programs outside ot the pure
academic area. Just look at the bugs in the OCaml and Haskell compilers.
>> Also it would be completely inacceptable to go back to the edit/compile/
>> run cycle, like it was in the 70ies.
>
> Then use the REPLs.
They don't have one. They have only interpreters.
>> The language standard yes, but the implementations not.
>
> Try to find a decent Lisp pattern matcher, for example.
Decent in what sense? PM are only syntactic sugar. They are good for
increasing productivity and make reading code easier, because they are
domain specific languages for what they do (like loop in lisp for exmaple).
There are several available in Lisp that are more extensible than those
that are built in into some FPL.
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> Then you were not writing your statically-typed code well.
>
> Real world programs...
Undefined.
>> I would love to see an example of dynamic typing being more productive
>> (say, faster or more concise).
>
> If this is true, I mean, if you really would love that, then start coding
> in Lisp. You will see that you run functions when they are not finished.
> You see how you change them in the running program. You can do small
> changes, just to see if your project benefits from going into that
> direction. This all must sound very mysterious to you, because you can't
> do that in your statically typed language that is also limited to the
> unmodern edit/compile/run cycle.
I've been using dynamically typed languages for decades.
> Just try out Lisp. I read that it was suggested before.
A lot of OCaml and Haskell programmers also know Lisp (not least the
inventors).
>> OCaml's type system cannot statically enforce primality, so you would
>> resort to run-time tests and maybe tag the int as being prime.
>
> In Lisp you can test this during compile time, easily for example by
> using Qi.
You can do the same thing in OCaml using macros.
>>> So, when you want to do static type checking you better use Lisp for
>>> that, because it catches even more errors at compile time.
>>> So the main argument for STC will lead you to Lisp anyways.
>>
>> Illogical. Why Lisp?
>
> Because it has the most powerful type system, see Qi.
Can you be more specific? What does Qi offer than OCaml and Haskell don't,
for example?
>>> Also it would be completely inacceptable to go back to the edit/compile/
>>> run cycle, like it was in the 70ies.
>>
>> Then use the REPLs.
>
> They don't have one. They have only interpreters.
Look at ocamlnat and F#.
>>> The language standard yes, but the implementations not.
>>
>> Try to find a decent Lisp pattern matcher, for example.
>
> Decent in what sense?
Correct and efficient.
> PM are only syntactic sugar.
Syntactic sugar doesn't do static verification and algorithmic optimization.
> ...There are several available in Lisp that are more extensible
> than those that are built in into some FPL.
OCaml's is arbitrarily extensible.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop schrieb:
> Andr� Thieme wrote:
>>> OCaml's type system cannot statically enforce primality, so you would
>>> resort to run-time tests and maybe tag the int as being prime.
>> In Lisp you can test this during compile time, easily for example by
>> using Qi.
>
> You can do the same thing in OCaml using macros.
Sure, you can. You can also do that for Java, Python and Basic. You only
have to run an external program that analysis characters and strings.
In Lisp (and Qi) it is easy and usable.
> Can you be more specific? What does Qi offer than OCaml and Haskell don't,
> for example?
Yes, look at the website I gave you.
>>>> The language standard yes, but the implementations not.
>>> Try to find a decent Lisp pattern matcher, for example.
>> Decent in what sense?
>
> Correct and efficient.
They are.
>> PM are only syntactic sugar.
>
> Syntactic sugar doesn't do static verification and algorithmic optimization.
Wrong, it can.
Andr� Thieme wrote:
> In Lisp (and Qi) it is easy and usable.
It is easy in many languages.
>> Can you be more specific? What does Qi offer than OCaml and Haskell
>> don't, for example?
>
> Yes, look at the website I gave you.
The website simply states over and over that Qi is more powerful.
>> Correct and efficient.
>
> They are.
Fare matcher is the only one bundled with SBCL and it is inefficient.
>> Syntactic sugar doesn't do static verification and algorithmic
>> optimization.
>
> Wrong, it can.
Then a theorem prover would be syntactic sugar over assembler, which is
clearly not meaningful. Syntactic sugar refers to semantically-invariant
syntactic rearrangements, not compiler features and optimizations.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> I've been using dynamically typed languages for decades.
>
> You are 29 years old.
I wish. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop escribi�:
> Andr� Thieme wrote:
>> Jon Harrop schrieb:
>>> I've been using dynamically typed languages for decades.
>> You are 29 years old.
>
> I wish. :-)
>
See: http://www.blogger.com/profile/11059316496121100950
Who are you lying to? Blogger, us or both?
Leandro
Leandro Rios wrote:
> See: http://www.blogger.com/profile/11059316496121100950
>
> Who are you lying to? Blogger, us or both?
Neither. Google has my correct DOB and is incorrectly calculating my age.
Probably a type error. ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop wrote:
>>See: http://<your privacy protected>
Under "favorite books" you list only one, which you wrote?
Marco, turn in all your "shameless plug" apologies.
kt
ps. You did not like "Lucky Jim"?
André Thieme <······························@justmail.de> writes:
> If I just work on some mathematical stuff then the problem domain is
> well specified - I can then work with a statically typed language.
> For real world programs this is just a small part of the story. You will
> have to do a run time analysis of the data anyway. But if you then have
> a system that is more dynamic you profit from that. If you would just
> try it out you would see it. But you will probably be working on some
> mathentical stuff, mostly interesting for academic uses where you simply
> don't experience enough disadvantages of using a statically typed system
> to try out something else.
Haha. I work with mostly numerical algorithms, and I found statically
typed languages a pain in the rear end. True, you can "implement" an
algorithm you worked out with pencil and paper, but after testing (or
even before, while writing the code) you might realize that another
algorithm would be faster or work better, then you rewrite, etc. Lisp
is ideal for _real-life_ numerical code.
To reinforce the point: most of the code I write involves math, and
has purely academic uses (solving economic models). But after using
Lisp for a few months, supporters of statically typed languages would
have to pry it from my cold, dead fingers ;-)
Tamas
On Jul 1, 2:53 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Lots of people here now agree that pattern matching is useful. It would be
> nice to have a decent pattern matcher in Lisp, preferably a good standard
> one that is bundled but a defacto-standard library would be almost as good.
> Lots of people have said they will write one over the past few years. Still
> nobody has.
I do not understand your reasoning: at one point you are saying Lisp
is outdated and must become retired at another point you spend huge
efforts to convince Lisp people that they should include fully-fledged
pattern matching facilities.
Let me ask: if you don't care on Lisp why do you care on Lisp
eventually?
I could somehow understand that people using Lisp on a daily basis
request some additional cool stuff but I cannot understand the other
way round. Why not Lisp people just going to fa.caml and convincing
people there to abadon pattern matching?