This has been reposted to haskell.org after it didn't seem to get through
via dcs.ed.ac.uk. If you get this twice, many apologies.
________________
After a few years writing VC++ for banks and financial institutions, I've
now reached a point where I have found a valid excuse to use a functional
programming language in anger. I got interested in ML at the beginning of
the 90s, moving on to Haskell some time later, but this interest got
squashed as I left academia and went back into commercial software
development.
Over the past couple of years I've developed a large (350k + lines of VC++)
database system, Telergy. It can be thought of as a real-time
AltaVista/Yahoo/Excite/Whatever, where rather than indexes being updated
every few days, its index is updated continuously in real-time. A Telergy
query looks a bit like a Boolean expression, except that 'not' is binary
rather than unary. Unlike SQL, once a Telergy query is opened, it stays open
until you explicitly close it - all updates that reference the query while
it is open are routed immediately to the client. This makes Telergy ideal as
a news and price distribution platform for the financial markets, which is
in fact what it is being used for by a number of banks already.
So far, the client applications that use Telergy have been predominantly
'thick', in that they are dedicated applications written in VC++ and Java.
However, there is very strong interest in being able to use Telergy directly
from a web browser, with Telergy serving HTML pages via HTTP directly. This
means that we now have a requirement to process a bunch of Telergy queries
and turn the results into HTML pages - the code for this looks horrible in
C, C++ or Java and even worse in VB or Perl, mostly because Telergy queries
are lazy in nature (i.e. you open them and they deliver results as and when
they are available, with a non-strict semantics). You can't easily
encapsulate a Telergy query in a procedural language without polling or
multiple threads - however, a Telergy query can be encapsulated trivially as
an infinite lazy list. This is what has led me back to Haskell after these
years - I need a language that has lazy evaluation, good performance and
good support for parsing and code generation.
I've done some preliminary playing around with HUGS and GHC, which has
generated a number of questions. Some of these questions I could probably
figure out given a week or two, so I must apologise for my laziness in
asking them here - feel free to ignore them or flame me to pieces if this
offends you. Others really need a response from someone in the know,
so-to-speak, so here goes:
1. (This question applies both to HUGS and GHC, because both systems are
potentially usable in our application). What is the position in terms of
using Haskell in a commercial project? Are there any direct or indirect
license fees required for commercial use? We can not countenance any kind of
license that would force us to go open source, because we are a tiny
software house (3 people) dealing with a vast unscrupulous ogre of a
multinational company, which would stamp on us in a nanosecond if it thought
it could do without us. Unfortunately, holding on to our source tree is the
only thing keeping us in employment at the moment.
2. What would the commercial implications be for wanting to redistribute
the GHC environment (or HUGS), rather than just compiled code? This is
important, because when we do start to market Telergy more widely, we'd like
to be able to deliver the development tools necessary along with it.
3. What is the best way to interface an existing API to Haskell, given
that the API has a Win32 DLL style interface? Is it better to reimplement
the interface as a COM interface, or figure out the necessary IDL code that
would allow it to link directly?
4. What is the most efficient way to return longish strings from an
external API to Haskell? Is it better to use a BSTR under COM, or can an
interface like:
BOOL DifGetNextMessage(DWORD handle, LPSTR buffer, LPDWORD buffsize);
which returns TRUE on success, or FALSE if the buffer is too small (at the
same time setting buffsize to the correct length).
Assuming we can get this all working, there are quite a few fun things that
will be possible - the boring stuff is just taking Telergy messages and
encapsulating them in web pages, but that would just be the first steps.
Possibilities like scanning news wires in real time using NL understanding
techniques to get market prediction cues for AI trading, text summarising,
testing NNs with live market data come to mind immediately - I'm sure there
is plenty more to be explored, however. It would be extremely interesting in
particular to see how straightforwardly an English query front-end could be
adapted to generate Telergy queries. Is anyone from the Durham AI team on
the list?
Thanks in advance,
Sarah Thompson
CEO, Telergy Software International Ltd.
PS: Should this product be a success in its use of GHC and/or HUGS
commercially, I'd see no problems in saying thank-you by helping financially
support further development of the compilers - the extent of this support
would for obvious reasons depend on the level of financial success the
product has, but sponsoring one or more PhD places should be very feasible.
I'd personally prefer this to a more formal commercial arrangement if
possible, having once been in a position of needing to find funding for my
own studies and wishing to make some kind of contribution.
