Ah, David! You are the person I want to be when I grow up :-).

On Fri, Jan 29, 2010 at 6:56 PM, David McClain
<dbm_at_refined-audiometrics.com> wrote:
>
> May I ask why you are attempting the punishing feat of producing a
> language written in Forth? You have already used the most appropriate
> languages for this purpose. Is it the notion that Forth can produce
> standalone DLL's more easily than these other languages?

Consider two use cases

1) Traders like NinjaTrader (http://www.ninjatrader.com), a trading
platform you can program in C#. They want to use it but have a large
baggage of EasyLanguage code. They don't want to translate it to C#
manually and would rather use a translation tool.

2) Trading systems developers like to sell indicators and systems to
other TradeStation (http://www.tradestation.com) users but the format
used to save them is easy to crack. Compiling trading systems written
in EasyLanguage to machine code would make them much more secure.
TradeStation allows for loading of DLLs so the compiled system would
be just a black box that generates trading signals.

My first idea for case #1 was to output C# code that can be used in
NinjaTrader. The problem with that approach is that NinjaTrader needs
a large library of functions that exist in TradeStation for any
EasyLanguage code to work. So could spend a fair amount of time
writing this EasyLanguage portability layer but then a prospect comes
along and asks me to write a translator that targets RightEdge
(http://www.rightedgesystems.com/).

RightEdge, OpenQuant (http://www.smartquant.com) and a bunch of others
use C# but they all have different interfaces. I would need to write
the EasyLanguage portability layer for each one, a boring task I don't
relish. Also, while the market for all trading platforms may be
significant, the market for each individual one is not.

This brings me to the idea to writing the EasyLanguage portability
layer once, as my own trading runtime in a DLL. Put that together
with the translated EasyLanguage code and you have something that can
be used as a black box in all trading platforms, with minimal C# or
other wrapping. This works for use case #2 just as well.

Now, my goal is to find a way to have a 'runtime' DLL that can load
translated code and execute it. This is not a job for Haskell which is
BIG and slow. It's not a job for OCaml since it's a pain in the rear
on Windows and for other reasons. Lisp is a good contender so let's
consider it.

There are 2 commercial Lisp vendors: Lispworks and Franz. I cannot use
the former since a program I deliver using the Lispworks compiler
cannot deliver code in turn, i.e. produce machine code. It's simply
not allowed by Lispworks. Franz allows this and I have free use of
their (expensive) tools. Franz also requires royalties in the single
digits.

What bugs me is that my Lisp DLL would weigh in at a megabyte or a few
and I have no idea how error-prone is the process of having my DLL
load code whilst running within some other trading platform. The user
will likely need to supply the path to translated machine code when
initializing the DLL. What if they get the path wrong? The support
burden here could be extensive.

To summarize, Lisp should work and so should, for example, Factor. It
would require a virtual machine running in a DLL that loads the
translated code, i.e. two pieces that need to be put together to make
a multi-megabyte whole.

In my ideal world my compiler should produce a single small DLL, just
a few kilobytes perhaps, a self-contained black box. There should be
no errors if the DLL is properly generated, no potential breaking
pieces. Also, I like small!

-- 
http://es.linkedin.com/in/joelreymont
----------------------------------------------------------------------
sftalk_at_forth.com      The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users.  For product support and
bug reports, please send email to support_at_forth.com
----------------------------------------------------------------------