Hi Joel,

Interesting feedback.

As for LW, I believe the restriction is that you cannot deliver a Lisp
compiler with your code. But your code is certainly free to generate
its own machine code and your own compiler all without any restrictions.

But back to small, and fast. By choosing to do this work in Forth, you
are trading off speed of development for speed of implementation. Size
apart. Today, all machines that I work with, even embedded processors,
have many GB of storage space, so size should no longer be a
determining factor the way it was when all we had were KIM-1's,
AIM-65's, PDP-11/35's and Nova 800's (typically memory sizes between 1
KB and 32 KW).

There is no question that you can develop a small and highly tuned app
in Forth to do what you want. But what you are finding is that for the
barest support of language design tasks, e.g., symbols -- there are no
such things inherent to the language Forth. So you have to roll your
own. Lists do not exist as a native data type, so you have to roll
your own, and so on.

But you do have direct control over what memory gets allocated for
what and where and how much. But that is what makes for slow going in
Forth too. All of the details normally handled by the higher level
language environments have to be your responsibility now.

I don't envy your task of developing a common interface to all the
various vendor platforms. That would be painful in any language. The
best you can hope for is to derive your own minimal working set of
primitives that your code needs, and then make a translation of those
core primitives to whatever the vendors provide.

And no doubt, most of your customers won't be proficient in C#. Your
language is probably a very domain specific language offering just
what traders want. And that is the best choice to offer them.

I still keep a keen eye open for the right place to use Forth in our
embedded systems. But with all the memory available, and the
increasing sophistication of embedded algorithms -- e.g., dynamic
adaptive channel equalization in 10 Gbps radio links, it becomes ever
more important to have higher levels of abstract reasoning. And all
those low level details in Forth derail such efforts. But I'm sure
Chuck would be the first to disagree with me, as usual... Heh!

- DM

On Jan 29, 2010, at 12:32 PM, Joel Reymont wrote:

> 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
> ----------------------------------------------------------------------
>
>

Dr. David McClain
dbm_at_refined-audiometrics.com

----------------------------------------------------------------------
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
----------------------------------------------------------------------
Received on Fri Jan 29 2010 - 13:28:52 PST