From: Jon Harrop
Subject: F# more popular than Common Lisp
Date: 
Message-ID: <13f3t5j2guuip26@corp.supernews.com>
This Google trend illustrates the shocking revelation that Lisp's corpse is
still twitching:

http://www.google.com/trends?q=f%23%2Ccommon+lisp

Best start moving the eggs out of the metacircular basket...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet

From: Dimiter "malkia" Stanev
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <5lecu6F7isspU2@mid.individual.net>
Who would even come with better name than F***'d Sharp.
From: D Herring
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <rvqdnVAad465amzbnZ2dnUVZ_tajnZ2d@comcast.com>
Jon Harrop wrote:
> This Google trend illustrates the shocking revelation that Lisp's corpse is
> still twitching:
> 
> http://www.google.com/trends?q=f%23%2Ccommon+lisp
> 
> Best start moving the eggs out of the metacircular basket...

Scale corrections:
http://www.google.com/trends?q=f%23%2Clisp
http://www.google.com/trends?q=f%23%2Clisp%2Cc%2B%2B

In fact, SBCL alone is competitive with all of F#.  ;)
http://www.google.com/trends?q=f%23%2Csbcl

But seriously, how can it compete with webpages such as
···@K the Burnside Couplet guest column"?

Thanks for the laugh,
Daniel
From: Carlo Capocasa
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <fct1ac$d2b$1@registered.motzarella.org>
> But seriously, how can it compete with webpages such as
> ···@K the Burnside Couplet guest column"?

*snicker*

Check the 'view more' pages and remove the 'Common Lisp' search term
to derive the ture ubiquity of F#.

"power makes you really ···@in annoying..."

"no, you can't have your ···@ing convention"

"F#%*, it's a huge problem."

and the almighty

"in G major, This lets us know any written F is played as F#. ... so
From D major to a major we retain the F# and C# and add aG# to
create a half-step ... "

That last one must be one of the most understandable programming
manuals MS has ever delivered.
From: Raffael Cavallaro
Subject: Harrop bigger troll than Gavino
Date: 
Message-ID: <2007092000432443658-raffaelcavallaro@pasdespamsilvousplaitmaccom>
If only frog-boy could get Gavino interested in F# ...
From: Tim Bradshaw
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190282648.289323.250900@22g2000hsm.googlegroups.com>
On Sep 20, 5:08 am, Jon Harrop <····@ffconsultancy.com> wrote:

>
> http://www.google.com/trends?q=f%23%2Ccommon+lisp
>

Of course, this changes over time.  When I started I used to play n
these sharp keys all the time - all the open strings on a guitar (in
standard tuning) are fine in C, G and D, and you lose 1 in A & 2 in
E.  G and D are particularly friendly, and both have F# as a fairly
prominent note (leading note in G, third in D). Going the other way
you lose the B string immediately in F, and it gets worse from there -
in B flat you've lost three strings including both Es.  Much harder to
play.

But then you find loads of blues and jazz stuff which is in these flat
keys, and you learn to cope.  (Also loads of blues things uses open
tunings with capos so all bets are off then - I quite like an open G
capoes to the third fret where it's an open B flat). And the flat keys
are kind of darker, which is always good of course.

And of course loads of woodwind-family instruments are in B flat
anyway.

I'm not actually sure why you're talking about music on a Lisp
newsgroup, though.  Aren't you the same guy that keeps going on about
Irish Camels as well?  You may want to seek professional help for
that, I think it's probably illegal.

--tim
From: Alan Crowe
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <86lkb1tmai.fsf@cawtech.freeserve.co.uk>
Tim Bradshaw <··········@tfeb.org> writes:

> Of course, this changes over time.  When I started I used to play n
> these sharp keys all the time - all the open strings on a guitar (in
> standard tuning) are fine in C, G and D, and you lose 1 in A & 2 in
> E.  G and D are particularly friendly, and both have F# as a fairly
> prominent note (leading note in G, third in D). Going the other way
> you lose the B string immediately in F, and it gets worse from there -
> in B flat you've lost three strings including both Es.  Much harder to
> play.
> 
> But then you find loads of blues and jazz stuff which is in these flat
> keys, and you learn to cope.  (Also loads of blues things uses open
> tunings with capos so all bets are off then - I quite like an open G
> capoes to the third fret where it's an open B flat). And the flat keys
> are kind of darker, which is always good of course.
> 

I remember, back in the 20's, when Late Romanticism was
giving way to Atonality. You couldn't write in C major any
more. You had to use the tri-tone all the time, even though
it sounded horrible.

What drove this change? In a word "consultancy". You had to
pay consults to tell you how to do without tunes and go from
C to F# and like it. And all because the Berg and Webern and
that lot needed the consultancy fees. 

Alan Crowe
Auld Reekie
Mid-Lothian
From: Jon Harrop
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <13f56cu55idfsf0@corp.supernews.com>
Tim Bradshaw wrote:
> I'm not actually sure why you're talking about music on a Lisp
> newsgroup, though.

So the F# musical note has grown tremendously in popularity since the
release of Robert Pickering's book on the F# programming language?
Interesting conclusion...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Tim Bradshaw
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190372097.579778.102340@22g2000hsm.googlegroups.com>
On Sep 20, 4:52 pm, Jon Harrop <····@ffconsultancy.com> wrote:

> So the F# musical note has grown tremendously in popularity since the
> release of Robert Pickering's book on the F# programming language?
> Interesting conclusion...

I really must apologise.  I was doing something we call "taking the
piss".  I reallise that's a concept you find hard to grasp (probably
it doesn't have a well-defined type or something).  Sorry
From: Christophe
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190288824.844702.295610@y42g2000hsy.googlegroups.com>
On 20 sep, 06:08, Jon Harrop <····@ffconsultancy.com> wrote:
> This Google trend illustrates the shocking revelation that Lisp's corpse is
> still twitching:
>
> http://www.google.com/trends?q=f%23%2Ccommon+lisp
>
> Best start moving the eggs out of the metacircular basket...
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> OCaml for Scientistshttp://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet

Hello,

Try again : http://www.google.com/trends?q=f%23%2C+scheme&ctab=0&geo=all&date=all&sort=0
... game over ?!

Regards
From: Ken Tilton
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <4_vIi.467$GW.365@newsfe12.lga>
Christophe wrote:
> On 20 sep, 06:08, Jon Harrop <····@ffconsultancy.com> wrote:
> 
>>This Google trend illustrates the shocking revelation that Lisp's corpse is
>>still twitching:
>>
>>http://www.google.com/trends?q=f%23%2Ccommon+lisp
>>
>>Best start moving the eggs out of the metacircular basket...
>>
>>--
>>Dr Jon D Harrop, Flying Frog Consultancy
>>OCaml for Scientistshttp://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
> 
> 
> Hello,
> 
> Try again : http://www.google.com/trends?q=f%23%2C+scheme&ctab=0&geo=all&date=all&sort=0
> ... game over ?!
> 
> Regards
> 

Cool. If you click on "more news results" you come to:

    "Guy Steele Condemned to Java for Scheme to kill Lisp"

kenny


-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Jon Harrop
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <13f569flm96v1ef@corp.supernews.com>
Christophe wrote:
> Try again :
>
http://www.google.com/trends?q=f%23%2C+scheme&ctab=0&geo=all&date=all&sort=0
> ... game over ?!
> 
> Regards

Homonym.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Pillsy
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190295902.536618.188470@o80g2000hse.googlegroups.com>
On Sep 20, 12:08 am, Jon Harrop <····@ffconsultancy.com> wrote:
> This Google trend illustrates the shocking revelation that Lisp's corpse is
> still twitching:

> http://www.google.com/trends?q=f%23%2Ccommon+lisp

> Best start moving the eggs out of the metacircular basket...

So you're trying to say a hip new language being developed and hyped
by Microsoft, targeted at the fashionable .NET platform is getting
roughly as much attention as a language that, when you come right down
to it, is 50 years old?

Well, hold the fucking phone. If these trends continue, F# might even
overtake Fortran before 2015!

http://www.google.com/trends?q=fortran%2Cf%23&ctab=0&geo=all&date=all&sort=0

Cheers,
Pillsy
From: Carlo Capocasa
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <fct0i2$bd4$1@registered.motzarella.org>
LOL!!!

What a correlation, apparently every time someone says f#*k, that
marks a key turning port for Microsoft's newest prize. I wonder what
your AdSense look like when you proudly announce: This site is all
about F#!

Carlo

PS: This, of course, deserves its very own permanent habitat.

http://picfu.com/link/88/09037eea809316a9
From: Leandro Rios
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <46f26bcd$0$1346$834e42db@reader.greatnowhere.com>
Jon Harrop escribi�:
> This Google trend illustrates the shocking revelation that Lisp's corpse is
> still twitching:
> 
> http://www.google.com/trends?q=f%23%2Ccommon+lisp
> 
> Best start moving the eggs out of the metacircular basket...

> Dr Jon D Harrop, Flying Frog Consultancy

He must be the second plague of Egypt the Exodus talks about.
From: smallpond
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190311028.395883.173400@19g2000hsx.googlegroups.com>
On Sep 20, 12:08 am, Jon Harrop <····@ffconsultancy.com> wrote:
> This Google trend illustrates the shocking revelation that Lisp's corpse is
> still twitching:
>
> http://www.google.com/trends?q=f%23%2Ccommon+lisp
>
> Best start moving the eggs out of the metacircular basket...
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> OCaml for Scientistshttp://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet



Can you explain why a static type language would not require type
declarations?
Is it just laziness?
Just curious.
--S
From: Raffael Cavallaro
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <2007092014170975249-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-09-20 13:57:08 -0400, smallpond <·········@juno.com> said:

> Can you explain why a static type language would not require type
> declarations?

<http://en.wikipedia.org/wiki/Type_inference>
From: Ken Tilton
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <OOAIi.487$GW.247@newsfe12.lga>
smallpond wrote:
> On Sep 20, 12:08 am, Jon Harrop <····@ffconsultancy.com> wrote:
> 
>>This Google trend illustrates the shocking revelation that Lisp's corpse is
>>still twitching:
>>
>>http://www.google.com/trends?q=f%23%2Ccommon+lisp
>>
>>Best start moving the eggs out of the metacircular basket...
>>
>>--
>>Dr Jon D Harrop, Flying Frog Consultancy
>>OCaml for Scientistshttp://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
> 
> 
> 
> 
> Can you explain why a static type language would not require type
> declarations?
> Is it just laziness?
> Just curious.

No problem, that's a great question. We have this thing called type 
inferencing, and now you get to wrestle with the compiler over not just 
the things you told it, but over all the extra things it figures out for 
yourself. So in the end you end up doing /more/ work, because the 
compiler is forever finding some inconsistency in what it thinks you are 
doing. It's like one of those games where you push down one thing and 
another one pops up and you go nuts trying to get them all down long 
enough to actual run your program.

hth, kenny (newest signup for F#)
From: Alex Mizrahi
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <46f41199$0$90270$14726298@news.sunsite.dk>
(message (Hello 'smallpond)
(you :wrote  :on '(Fri, 21 Sep 2007 06:30:45 -0700))
(

 s> I was just wondering
 s> if there is some advantage to it other than saving a few lines
 s> of declarations.

yes. basically it's the same advantage as making a function has over 
copy-pasting code -- you change only few declaration in well-defined points, 
and type-inferencer will check all the surrounding code automatically. 
automatization is advantage, isn't it?

actually i find static type checking quite nice, so i think it would be 
interesting if some Lisp impementation could offer *optional* checking. to 
my knowledge some implementations like SBCL do some checking, but they judge 
mainly from performance reasons rather than correctness

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"Hanging In The Balance Of Deceit And Blasphemy") 
From: smallpond
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190402481.520863.104170@w3g2000hsg.googlegroups.com>
On Sep 21, 2:46 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> (message (Hello 'smallpond)
> (you :wrote  :on '(Fri, 21 Sep 2007 06:30:45 -0700))
> (
>
>  s> I was just wondering
>  s> if there is some advantage to it other than saving a few lines
>  s> of declarations.
>
> yes. basically it's the same advantage as making a function has over
> copy-pasting code -- you change only few declaration in well-defined points,
> and type-inferencer will check all the surrounding code automatically.
> automatization is advantage, isn't it?
>
> actually i find static type checking quite nice, so i think it would be
> interesting if some Lisp impementation could offer *optional* checking. to
> my knowledge some implementations like SBCL do some checking, but they judge
> mainly from performance reasons rather than correctness
>
> )
> (With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
> "Hanging In The Balance Of Deceit And Blasphemy")



I don't see a reason why a lisp compiler couldn't determine that
a function is always being called with data of a given type,
and generate the equivalent of static typed code.  It doesn't
seem to be a harder problem than type inference.
--S
From: Matthias Buelow
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <5lil2iF8ffcsU1@mid.dfncis.de>
smallpond wrote:
> I don't see a reason why a lisp compiler couldn't determine that
> a function is always being called with data of a given type,
> and generate the equivalent of static typed code.  It doesn't
> seem to be a harder problem than type inference.

It is undecidable; just like generic type inference is undecidable. The
type inference scheme being used for statically typed languages is
actually a decidable subset that puts some constraints on what are legal
types.
From: Klaus Schilling
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <87ir63umf8.fsf@web.de>
smallpond <·········@juno.com> writes:
>
> I don't see a reason why a lisp compiler couldn't determine that
> a function is always being called with data of a given type,

if the type is only known at runtime, that's not possible

Klaus Schilling
From: Jon Harrop
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <13fh3h0ipo8ah62@corp.supernews.com>
Alex Mizrahi wrote:
> actually i find static type checking quite nice, so i think it would be
> interesting if some Lisp impementation could offer *optional* checking. to
> my knowledge some implementations like SBCL do some checking, but they
> judge mainly from performance reasons rather than correctness

There are really two problems here:

1. Lisp compilers like SBCL realise that static type checking is highly
desirable and do their best to check types at compile time but they cannot
without a well designed type system (like, say, OCaml's).

2. You would want to choose to check some parts but not other parts of your
program, which would greatly diminish the utility of static type checking
as the types of the unchecked parts would not be known and could not even
be declared by a Lisper because they are blissfully unaware of types,
knowing only how to trawl through run-time error traces and write unit
tests instead.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Klaus Schilling
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <87abrbmh5p.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
>
>  static type checking is highly
> desirable

no, it isn't desirable, as it limits run-time flexibility

Klaus Schilling
From: George Neuner
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <nucif3plav9alp22b0gq5pjrqlcsrnm082@4ax.com>
On Fri, 21 Sep 2007 21:46:42 +0300, "Alex Mizrahi"
<········@users.sourceforge.net> wrote:

>actually i find static type checking quite nice, so i think it would be 
>interesting if some Lisp impementation could offer *optional* checking.

If you can stand infix (or can find an old sexpr version) you could
try Dylan.  It defaults to latent typing, but you can add as few or as
many type declarations as you wish and the compiler will elide runtime
checking for any code it can prove statically safe.

The warts are: no type inferencing (static typing is manual) and
modern versions of Dylan have conventional infix syntax (the original
sexpr syntax was eliminated).

George
--
for email reply remove "/" from address
From: Jon Harrop
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <13f5lk2l9i2ui46@corp.supernews.com>
smallpond wrote:
> Can you explain why a static type language would not require type
> declarations?

You can write code in OCaml such that the types are inferred rather than
explicitly declared.

> Is it just laziness?

It is a trade-off. Using inferred types like tuples and polymorphic variants
in OCaml has some of the pros and cons of dynamic typing:

. There are no type declarations to maintain as the program evolves: makes
exploratory programming easier but can obfuscate errors.

. Inferred types convey weaker type information: makes code more generic but
slower and less rigorously checked.

In practice, OCaml programmers use both inferred and declared types. When
developing a complicated program, you start with inferred types and move to
more declared types as the design is pinned down and the static type
information conveys machine-verified documentation and interfaces, improves
performance and so on. Reliability comes from static checking rather than
unit tests and most fixes come from statically-generated error messages
rather than traces after run-time failures.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: smallpond
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190327914.159975.272300@r29g2000hsg.googlegroups.com>
On Sep 20, 4:12 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> smallpond wrote:
> > Can you explain why a static type language would not require type
> > declarations?
>
> You can write code in OCaml such that the types are inferred rather than
> explicitly declared.
>
> > Is it just laziness?
>
> It is a trade-off. Using inferred types like tuples and polymorphic variants
> in OCaml has some of the pros and cons of dynamic typing:
>
> . There are no type declarations to maintain as the program evolves: makes
> exploratory programming easier but can obfuscate errors.
>
> . Inferred types convey weaker type information: makes code more generic but
> slower and less rigorously checked.
>
> In practice, OCaml programmers use both inferred and declared types. When
> developing a complicated program, you start with inferred types and move to
> more declared types as the design is pinned down and the static type
> information conveys machine-verified documentation and interfaces, improves
> performance and so on. Reliability comes from static checking rather than
> unit tests and most fixes come from statically-generated error messages
> rather than traces after run-time failures.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> OCaml for Scientistshttp://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet



So if I write a polymorphic "function_of_any" and call it
with a type a and in another place with a type b, does the
OCaml compiler generate two functions: "function_of_a"
and "function_of_b"?
--S
From: Ken Tilton
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <YtHIi.202$mS7.104@newsfe12.lga>
smallpond wrote:
> On Sep 20, 4:12 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> 
>>smallpond wrote:
>>
>>>Can you explain why a static type language would not require type
>>>declarations?
>>
>>You can write code in OCaml such that the types are inferred rather than
>>explicitly declared.
>>
>>
>>>Is it just laziness?
>>
>>It is a trade-off. Using inferred types like tuples and polymorphic variants
>>in OCaml has some of the pros and cons of dynamic typing:
>>
>>. There are no type declarations to maintain as the program evolves: makes
>>exploratory programming easier but can obfuscate errors.
>>
>>. Inferred types convey weaker type information: makes code more generic but
>>slower and less rigorously checked.
>>
>>In practice, OCaml programmers use both inferred and declared types. When
>>developing a complicated program, you start with inferred types and move to
>>more declared types as the design is pinned down and the static type
>>information conveys machine-verified documentation and interfaces, improves
>>performance and so on. Reliability comes from static checking rather than
>>unit tests and most fixes come from statically-generated error messages
>>rather than traces after run-time failures.
>>
>>--
>>Dr Jon D Harrop, Flying Frog Consultancy
>>OCaml for Scientistshttp://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
> 
> 
> 
> 
> So if I write a polymorphic "function_of_any" and call it
> with a type a and in another place with a type b, does the
> OCaml compiler generate two functions: "function_of_a"
> and "function_of_b"?

Actually it generates twenty-six, one for each letter of the alphabet. 
This is the genius of F#. Dr. Harrop and I have been working on an FAQ 
for precisely this little gotcha, you can find it over here:

    http://www.theoryyalgebra.com/Reviews.html

hth, kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Matthias Buelow
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <5lgbqkF85e4vU1@mid.dfncis.de>
smallpond wrote:

> So if I write a polymorphic "function_of_any" and call it
> with a type a and in another place with a type b, does the
> OCaml compiler generate two functions: "function_of_a"
> and "function_of_b"?

No, if the function is polymorphic and A and B are admissible types
under this polymorphism (I'm sure the exact terminology is different),
then the function doesn't inspect any of the details that differentiate
A from B. For example, a function which computes the length of a list
does not need to know the types of the elements on that list.
It's like in other programming languages, if you have a function to add
two integers, it won't generate 2^2^32 (for example) functions for all
possible value combinations, just one, of course.
From: smallpond
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190346544.644817.130110@w3g2000hsg.googlegroups.com>
On Sep 20, 6:52 pm, Matthias Buelow <····@incubus.de> wrote:
> smallpond wrote:
> > So if I write a polymorphic "function_of_any" and call it
> > with a type a and in another place with a type b, does the
> > OCaml compiler generate two functions: "function_of_a"
> > and "function_of_b"?
>
> No, if the function is polymorphic and A and B are admissible types
> under this polymorphism (I'm sure the exact terminology is different),
> then the function doesn't inspect any of the details that differentiate
> A from B. For example, a function which computes the length of a list
> does not need to know the types of the elements on that list.
> It's like in other programming languages, if you have a function to add
> two integers, it won't generate 2^2^32 (for example) functions for all
> possible value combinations, just one, of course.


I was thinking of something like the typical polymorphic stack
functions: pop and push.  Push allocates enough space for that
type and a link, copies the contents and links to the next.  Pop
undos.  Dynamic typed languages ask the object how big it is
but static typed languages know at compile time.
--S
From: Matthias Buelow
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <5li5fjF89647U1@mid.dfncis.de>
smallpond wrote:

> I was thinking of something like the typical polymorphic stack
> functions: pop and push.  Push allocates enough space for that
> type and a link, copies the contents and links to the next.  Pop
> undos.  Dynamic typed languages ask the object how big it is
> but static typed languages know at compile time.

I don't know what you mean by "typical"; in Lisp, push/pop normally[1]
don't copy an object, they prepend/remove it to/from the front of a
list, which involves nothing more than storing a pointer to the object
in the cons cell's car, so there's no need to know anything about the
object.

In statically strongly typed languages such as Standard ML, lists
typically are monomorphic (can only store elements of a particular type,
the element type is part of the list type), so the issue doesn't arise
(and there, values pushed on the list also usually aren't copied).

Could you give an example of a copying push/pop?


[1] Unless it is a small value such as a fixnum integer, character,
etc., that may be inlined in the car, but that's system-dependent.
From: smallpond
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190407201.224122.172880@50g2000hsm.googlegroups.com>
On Sep 21, 11:16 am, Matthias Buelow <····@incubus.de> wrote:
> smallpond wrote:
> > I was thinking of something like the typical polymorphic stack
> > functions: pop and push.  Push allocates enough space for that
> > type and a link, copies the contents and links to the next.  Pop
> > undos.  Dynamic typed languages ask the object how big it is
> > but static typed languages know at compile time.
>
> I don't know what you mean by "typical"; in Lisp, push/pop normally[1]
> don't copy an object, they prepend/remove it to/from the front of a
> list, which involves nothing more than storing a pointer to the object
> in the cons cell's car, so there's no need to know anything about the
> object.
>
> In statically strongly typed languages such as Standard ML, lists
> typically are monomorphic (can only store elements of a particular type,
> the element type is part of the list type), so the issue doesn't arise
> (and there, values pushed on the list also usually aren't copied).
>
> Could you give an example of a copying push/pop?
>
> [1] Unless it is a small value such as a fixnum integer, character,
> etc., that may be inlined in the car, but that's system-dependent.


push and pop in lisp are macros.  Maybe a better example is
push and pop in perl which allows a list of mixed scalar
types.
--S
From: Matthias Buelow
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <5lipl6F8e5hfU1@mid.dfncis.de>
smallpond wrote:

> push and pop in lisp are macros.  Maybe a better example is
> push and pop in perl which allows a list of mixed scalar
> types.

I can't see how push/pop being macros comes into the discussion; what
exactly do you want to say? I don't think perl works fundamentally
different from Lisp in this regard (although I don't know perl much).
From: smallpond
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190411567.192274.258640@r29g2000hsg.googlegroups.com>
On Sep 21, 5:00 pm, Matthias Buelow <····@incubus.de> wrote:
> smallpond wrote:
> > push and pop in lisp are macros.  Maybe a better example is
> > push and pop in perl which allows a list of mixed scalar
> > types.
>
> I can't see how push/pop being macros comes into the discussion; what
> exactly do you want to say? I don't think perl works fundamentally
> different from Lisp in this regard (although I don't know perl much).


Ummm.  because we're talking about polymorphic functions?  and
because you asked for an example of a copying push and pop in a
dynamically typed language?  Maybe I don't understand what point
you're trying to get at, either.

My point was that if the performance improvement in a statically
typed language is due to eliminating runtime type checking, then
it seems like polymorphic functions would require generating
multiple type-specific versions of the code.
--S
From: Matthias Buelow
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <5lj3fmF8791iU1@mid.dfncis.de>
smallpond wrote:

> My point was that if the performance improvement in a statically
> typed language is due to eliminating runtime type checking, then
> it seems like polymorphic functions would require generating
> multiple type-specific versions of the code.

Ordinary type polymorphism doesn't work on disjunct types, so this is
not a possibility. Maybe you're thinking of C++ overloaded functions,
which are not type-polymorphic (they don't work over an infinite set
of admissible types but only for the ones specified; true type
polymorphism is available through function templates, however. Anyway,
C++ is a special case here and other strongly typed compile-time
checking languages with type polymorphism don't necessarily work the
same way.)

Type polymorphism works by specializing a function to the most
specialized supertype of all admissible types; for example, if a type
"number" exists, with subtypes integer and float, a function can
specialize on it and add both integers and floats. But if such a type
doesn't exist (like, for example, in ML), you can't write a function
that adds both integers and floats (at least not without extensions
such as functors).
From: smallpond
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190431962.360584.81690@w3g2000hsg.googlegroups.com>
On Sep 21, 7:48 pm, Matthias Buelow <····@incubus.de> wrote:
> smallpond wrote:
> > My point was that if the performance improvement in a statically
> > typed language is due to eliminating runtime type checking, then
> > it seems like polymorphic functions would require generating
> > multiple type-specific versions of the code.
>
> Ordinary type polymorphism doesn't work on disjunct types, so this is
> not a possibility. Maybe you're thinking of C++ overloaded functions,
> which are not type-polymorphic (they don't work over an infinite set
> of admissible types but only for the ones specified; true type
> polymorphism is available through function templates, however. Anyway,
> C++ is a special case here and other strongly typed compile-time
> checking languages with type polymorphism don't necessarily work the
> same way.)
>
> Type polymorphism works by specializing a function to the most
> specialized supertype of all admissible types; for example, if a type
> "number" exists, with subtypes integer and float, a function can
> specialize on it and add both integers and floats. But if such a type
> doesn't exist (like, for example, in ML), you can't write a function
> that adds both integers and floats (at least not without extensions
> such as functors).



C++ polymorphic functions do generate separate code for
every possible combination of admissible argument types, but
it is done explicity.  I was asking what a language with
type inference does when it claims to have polymorphic
functions.  Actually, I didn't think it was that hard a
question.
--S
From: Matthias Buelow
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <5lkp2sF8nq0aU1@mid.dfncis.de>
smallpond wrote:

> C++ polymorphic functions do generate separate code for
> every possible combination of admissible argument types, but
> it is done explicity.  I was asking what a language with
> type inference does when it claims to have polymorphic
> functions.  Actually, I didn't think it was that hard a
> question.

I recommend you read up on how the type systems work in the languages
you're interested in and then you probably can give one good answer
yourself (although it might not be the only valid one). It might also be
beneficial to read up on how the basic Hindley-Milner type inference
method works because that's the underlying mechanism being used by most
of those languages you probably have in mind. Whether to generate
separate code in some special cases (especially when inlining functions)
or not is a decision made by the compiler although you should learn
about the above to understand that in many of the cases you probably
have in mind (like the push/pop example), it simply isn't applicable.
From: Jon Harrop
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <13fh3m71j74cm63@corp.supernews.com>
smallpond wrote:
> My point was that if the performance improvement in a statically
> typed language is due to eliminating runtime type checking, then
> it seems like polymorphic functions would require generating
> multiple type-specific versions of the code.

OCaml takes a different approach where functions expect values in a uniform
representation. So they don't know if they're copying an int, a float, or a
reference to a tree. This way, you don't pay the price for either run-time
checks (Lisp) or code bloat (C++).

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Matthias Buelow
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <5ls1i1F9mgnoU1@mid.dfncis.de>
Jon Harrop wrote:

> OCaml takes a different approach where functions expect values in a uniform
> representation. So they don't know if they're copying an int, a float, or a
> reference to a tree.

Instead it would incur an overhead in handling integers (and pointers)
by boxing integers and addresses (32 bits on a 32-bit machine) in 64
bits (so that a double float would also fit)... I'm a bit doubtful about
that.
From: Jon Harrop
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <13fibh7n1jnmof1@corp.supernews.com>
Matthias Buelow wrote:
> Jon Harrop wrote:
>> OCaml takes a different approach where functions expect values in a
>> uniform representation. So they don't know if they're copying an int, a
>> float, or a reference to a tree.
> 
> Instead it would incur an overhead in handling integers (and pointers)
> by boxing integers and addresses (32 bits on a 32-bit machine) in 64
> bits (so that a double float would also fit)... I'm a bit doubtful about
> that.

Sorry, I should not have said floats as they are boxed by default. OCaml
replaces the boxing of ints with a single-bit tag (hence it has 31- and
63-bit ints). Good float performance is then achieved by aggressively
unboxing floats within function bodies, which works well because
float-intensive code is often written using for loops rather than
recursion.

Other compilers, like MLton, take different approaches but achieve similarly
good performance.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Damien Kick
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <13fm9fog3ngdd06@corp.supernews.com>
smallpond wrote:

> On Sep 20, 6:52 pm, Matthias Buelow <····@incubus.de> wrote:

>> smallpond wrote:

>>> So if I write a polymorphic [...], does the
>>> OCaml compiler generate two functions: "function_of_a"
>>> and "function_of_b"?

>> No, if the function is [...]

> I was thinking of something like the typical polymorphic stack
> functions: pop and push.  Push allocates enough space for that
> type and a link, copies the contents and links to the next.  Pop
> undos.  Dynamic typed languages ask the object how big it is
> but static typed languages know at compile time.

This is a good question.  You should ask it on comp.lang.ocaml.
From: Jon Harrop
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <13fh2r1epjp1461@corp.supernews.com>
smallpond wrote:
> So if I write a polymorphic "function_of_any" and call it
> with a type a and in another place with a type b, does the
> OCaml compiler generate two functions: "function_of_a"
> and "function_of_b"?

OCaml will generate a single function that works for both types (a and b).

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Stefan Scholl
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <0T4e2dnpIum0Nv8%stesch@parsec.no-spoon.de>
Jon Harrop <···@ffconsultancy.com> wrote:
> performance and so on. Reliability comes from static checking rather than
> unit tests and most fixes come from statically-generated error messages

So the answer a function gives is irrelevant, as long as the type
is OK? :-)


-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
From: Tim Bradshaw
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <1190371682.012507.106300@o80g2000hse.googlegroups.com>
On Sep 21, 7:37 am, Stefan Scholl <······@no-spoon.de> wrote:

> So the answer a function gives is irrelevant, as long as the type
> is OK? :-)

That's the idea.  Try not to laugh, though I admit it's hard.  I think
"liking static type systems" has recently been recognised as and
autistic spectrum disorder.  One has to feel sorry for these people.

--tim
From: Espen Vestre
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <m11wctpher.fsf@gazonk.netfonds.no>
Jon Harrop <···@ffconsultancy.com> writes:

> This Google trend illustrates the shocking revelation that Lisp's corpse is
> still twitching:
>
> http://www.google.com/trends?q=f%23%2Ccommon+lisp

You got it all wrong, Common Lisp is CL among friends, and it's much
more trendy than your four-letter language:

http://www.google.com/trends?q=f%23%2C+cl&ctab=0&geo=all&date=all&sort=0

Now could you please stop posting your ··@king googlitches for a while?
-- 
  (espen)
From: Larry Elmore
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <QqEIi.4985$6o2.1789@trnddc05>
Espen Vestre wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
> 
>> This Google trend illustrates the shocking revelation that Lisp's corpse is
>> still twitching:
>>
>> http://www.google.com/trends?q=f%23%2Ccommon+lisp
> 
> You got it all wrong, Common Lisp is CL among friends, and it's much
> more trendy than your four-letter language:
> 
> http://www.google.com/trends?q=f%23%2C+cl&ctab=0&geo=all&date=all&sort=0
> 
> Now could you please stop posting your ··@king googlitches for a while?

Yup, CLOS is doing well, too:

http://www.google.com/trends?q=f%23%2C+CLOS&ctab=0&geo=all&date=all&sort=0
From: John Thingstad
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <op.ty0kijtcpqzri1@pandora.upc.no>
P� Fri, 21 Sep 2007 02:41:20 +0200, skrev Larry Elmore  
<········@verizon.spammenot.net>:

> Espen Vestre wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>
>>> This Google trend illustrates the shocking revelation that Lisp's  
>>> corpse is
>>> still twitching:
>>>
>>> http://www.google.com/trends?q=f%23%2Ccommon+lisp
>>  You got it all wrong, Common Lisp is CL among friends, and it's much
>> more trendy than your four-letter language:
>>   
>> http://www.google.com/trends?q=f%23%2C+cl&ctab=0&geo=all&date=all&sort=0
>>  Now could you please stop posting your ··@king googlitches for a while?
>
> Yup, CLOS is doing well, too:
>
> http://www.google.com/trends?q=f%23%2C+CLOS&ctab=0&geo=all&date=all&sort=0


What the F#?.. Yes I think I see the reason for it's popularity.. RLOL
From: Cor Gest
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <871wcrops4.fsf@telesippa.clsnet.nl>
Do You also serve fries with that ?

Cor

-- 
	 (defvar MyComputer '((OS . "GNU/Emacs")(IPL . "GNU/Linux"))) 
     If all fails to satisfy you read the HyperSpec or info woman 
                Proud member of the Spamipuku Elite
		           http://www.clsnet.nl/mail.php
 
From: Giorgos Keramidas
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <87ir622u2k.fsf@kobe.laptop>
On Thu, 20 Sep 2007 05:08:40 +0100, Jon Harrop <···@ffconsultancy.com> wrote:
> This Google trend illustrates the shocking revelation that Lisp's corpse is
> still twitching:
>
> http://www.google.com/trends?q=f%23%2Ccommon+lisp
>
> Best start moving the eggs out of the metacircular basket...

I have a better idea.  We should all forget about Lisp and F# and start
programming in Visual Basic:

http://www.google.com/trends?q=f%23%2Cvisual+basic

Pffffffffffffft.
From: Espen Vestre
Subject: Re: F# more popular than Common Lisp
Date: 
Message-ID: <m1zlzda6e7.fsf@gazonk.vestre.net>
Giorgos Keramidas <········@ceid.upatras.gr> writes:

> On Thu, 20 Sep 2007 05:08:40 +0100, Jon Harrop <···@ffconsultancy.com> wrote:
>> This Google trend illustrates the shocking revelation that Lisp's corpse is
>> still twitching:
>>
>> http://www.google.com/trends?q=f%23%2Ccommon+lisp
>>
>> Best start moving the eggs out of the metacircular basket...
>
> I have a better idea.  We should all forget about Lisp and F# and start
> programming in Visual Basic:
>
> http://www.google.com/trends?q=f%23%2Cvisual+basic

Are you crazy? Didn't you notice the falling trend? Visual Basic will
soon be less popular than /spam/ and other utterly boring subjects:

http://www.google.com/trends?q=visual+basic%2C+spam%2C+concrete&ctab=0&geo=all&date=all&sort=0
-- 
  (espen)