New trading systems platform

[James Hague]

Richard O'Keefe wrote:

> What should {1,2} + {10,20,30} do, and why?

It should exit with a badarith code.  Why?  There's no clear meaning
to adding vectors of different lengths.  (I tried it in J and got back
"length error.").  Likewise, {1,2} + {1,two} should also result in
badarith.

> Erlang is a language with run-time types, not compile-time types.
> In such a language, *in*compatibilities between built-in types and
> operators are to be cherished, not discarded, lest errors go unreported.
> The difficulty of hacking a feature into the emulator is not the real
> issue, but conceptual integrity and the effect on other uses of the language.

True, I can understand that point.  But at the same time, with
test-driven development, I don't see it as any different than other
issues caused by dynamic typing.

> It might, for example, be better to introduce a whole new "array" data type;
> that would be much more work, but it could yield better performance (using
> long-known techniques from APL) without sacrificing any of the run-time
> type checking we now have.

Strictly from a selfish point of view based on the kind of
applications I work on, I'd like to see "array of float" as a
fundamental type.  Floats are individually heap allocated, so there's
a big win to putting them in a homogeneous array (OCaml has taken a
similar route).  This would also be a big space/time win for
applications like Wings3D.  But from a conceptual point of view,
arrays and tuples are the same thing, so why split them up?