Like nothing you've ever seen. There is a very small subset of the language vaguely resembling pure Lisp, and any program expressible in the language is expressible in this subset. However, programs are written mostly using operators representing functional combinators. There are no reserved words but libraries and user defined functions can be named (see these examples).
Financial engineers (a.k.a. quants) would benefit from all the high powered math and statistical library functions callable in the language, and from its interoperability with other mathematical packages such as GNU R and Octave. They would also save time by using a succinct mathematical notation compared to more verbose imperative or object oriented programming styles. Furthermore, there are some data structures and combinators unique to Ursala specifically supporting lattice models used in derivatives pricing problems.
Ursala has yet to be used in group projects, and would undoubtedly pose similar managerial challenges to other mathematical programming notations with regard to sourcing adequate talent. Its greatest appeal will be to a self-selected class of outstanding developers in the fortunate position of being unconstrained by the usual limitations of large organizations.
No. The language isn't suited for highly concurrent applications unless the developer is willing to have a separate instance of the virtual machine running for each thread. However, there are some facilities in support of locally or remotely spawned processes. These are system level processes without any shared state.
For numerical applications, the answer is a qualified yes if the developer arranges for the heavy lifting to be done by third party libraries such as LAPACK and GSL, which have convenient interfaces from the language, or any in-house C library integrated with the virtual machine's open architecture. Ursala excels at the data transformation and glue code that is less performance critical but might otherwise take a disproportionate amount of a developer's time.
Habitual use of the language begets its own peculiar development methodology wherein most if not all applications are viewed as compilation problems, transforming a data set from a source to a target representation. Complex problems are solved stepwise, with powerful facilities that allow setting of breakpoints, exception handling, and assertions. Intermediate data structures are readily accessible for display according to succinct format specifications similar to type expressions.
That depends on whether you write h(f)(x) (without
spaces) or h f x (with spaces, parentheses
optional). Only the latter is right associative (i.e., parsed as
h(f(x))), and only for the sake of being more in
keeping with standard mathematical conventions. There is no
reason for function application to be left associative in a
language without automatic currying, and no reason for
automatic currying in a language that distinguishes notationally
between product spaces and function spaces (unlike lambda
calculi).
The product of a pair of arbitrary precision numbers (in mpfr format) is allocated the greater precision of the two operands so that library functions incorporating hard coded constants can interoperate generically with numbers of any precision without explicit run-time checks or modifications. It is incumbent on the user to know how many digits are physically reliable.