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
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
> 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.
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
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
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
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
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
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
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
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
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
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.
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
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>
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#)
(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")
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
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
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
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
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
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
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
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.
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
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.
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
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).
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
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).
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
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.
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
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.
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
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.
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
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/
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
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)
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
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
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.
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)