FYI: F# language moves from lab into production

FYI: F# language moves from lab into production

Post by Marc » Sun, 24 Jan 2010 22:43:46


FYI: F# language moves from lab into production

Post by Jon Harro » Mon, 25 Jan 2010 10:32:06

F# moved from the lab into production with Somasegar's announcement back in
2007. Today, the version of F# now in beta release is basically what you'll
get in Visual Studio 2010 on 22nd March. You can even try it in the VS 2010

As for existing users of F#, the F# Hub has over 16,400 registered users. F#
is now the highest earning part of our business.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.


FYI: F# language moves from lab into production

Post by BGB / cr88 » Mon, 25 Jan 2010 15:40:06

"Jon Harrop" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

and, on another note:
more recently I am faced with .NET, and once again considering the
possibility of doing my own implementation (otherwise, if I were to make use
of it, I would be left to the graces that the target system has either MS's
implementation or Mono available...).

but, the CLI continues to look like one of those things which would be
horridly painful to implement...

among the many other issues, there is this one: what to do about the

the metadata is stored in a form which would be relatively awkward to
process in-place without making a mess, and doesn't look particularly easy
to wrap with a general-purpose API (unless I sit around using bit-packed
integer keys to access it).

unpacking the metadata into a different form seems possible, but I am not
certain if this is the "ideal" option.
such an "unpacked" representation could be either a more convinient form of
the tabular format, or it could be unpacked directly into my main database
format (basically, a windows-registery style heirarchical database), either
as a direct structural transcription, or as a structural/semantic

I have a slight worry though, since if the databases are anywhere near as
large as the CLI's bit-packing layout seems to imply, then the
representation used by my main database could waste lots of space (being
based around linked-lists of nodes, key/value pairs, and interned strings).

I guess I always could make the partial optimization of using a hack for
compressing integers into strings:
allowing the "string" to point into the space-region associated with fixnums
(integers embedded into pointers), which would be assumed (in this context)
to be a string containing a number...

granted, this would not save "that" much though, if faced with "teh
crapload" of metadata nodes (several million of nodes?...).

I guess, little stops me from keeping a similar semantic structure to my
current DB, but switching to a more memory-compact (and maybe more
efficient) in-memory structure.

then again, it could turn out like what was the case with dumping textual
versions of my C-based databases: they were actually surprisingly compact
(generally 10s or 100s of kB), even in their verbose textual-dump form (if
they were 10s of MB, I would have more reason to worry...).

note, if I were to access .NET metadata like in my main DB, this would
likely involve all requests being encoded as strings which are interpreted
as needed:
(totally ignoring here that .NET metadata is essentially a relational-table
style format, meaning that a path-based form is a questionable means of
fetching info...).

and, maybe unpacking binary signatures (on reference) into my VM's textual
format, mostly because the binary signatures also seem like a much bigger
hassle to mess with (they are ambiguous apart from knowing the particular
assembly, whereas my framework generally passes around signature strings
freely and assumes that they are universally understandable...).

or such...


FYI: F# language moves from lab into production

Post by Marc » Mon, 25 Jan 2010 21:14:36

Will there be an Express edition for language hobbyists?

FYI: F# language moves from lab into production

Post by Jon Harro » Tue, 26 Jan 2010 04:10:45

Yes. There will be an Express edition of VS2010 that makes F# freely
available to everyone. Moreover, it is not just for language hobbyists: you
can sell the code you compile with it.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.