On Fri 11 Aug, Manuel M. T. Chakravarty wrote:
> Erlang applications are characterised as being soft-realtime
> applications:
>
> http://www.erlang.org/faq/x847.html#SOFT-REALTIME
>
> In one sentence, I would characterise this as ``it is fast
> enough most of the time.'' This seems to be good enough for
> many (most?) embedded systems.
Yes, I think so, but terms like 'embedded','real time' amd 'non-deterministic'
seem to mean different things to different people. I won't attempt to
define them.
But as far as GC is concerned, time is really a secondary issue IMHO.
It's having confidence that your program can run in (known) bounded space
that worries me. (If you don't mind the wait, time can be extended
indefinitely, but you can't do this with memory).
Real time or not, presumably systems writtem in Erlang are required not to
conk out due to exhausted heap space. I don't see how Erlang users ensure
this, other than by relying on programmers intuition and program testing.
> I see your point about insisting on finite state machines,
> but as the functionality expected from embedded systems
> increases, this ideal viewpoint will become increasingly
> infeasible in practice.
In that case I suspect the systems we all rely on will become increasingly
unreliable :-( This is probably less of a problem for strict languages
because it's much easier for the programmer to think about the space
behaviour of programs, but in a graph reduction implementation (of a lazy
language) things aren't so easy. This worries me.
Are heap profilers the answer, I wonder? Certainly they help detect space
leaks, but this reliance on empirical rather than analytical methods
doesn't really seem to be consistent with the goal of being able to write
programs which are correct by design, and provably so (in principal at least).
Just curious, but has anybody investigated how far you can go with a
'purely functional' language and still get a finite state machine
implementation?
What would you need to do to Haskell to achieve this? Obvious things
which come to mind include outlawing recursive data types (including our
beloved lists!). This seems a little drastic, maybe you could allow them but
'deforest' them out in many cases (and have the compiler warn you if it
couldn't). I suppose they would be ok in (finite) constants too.
Just a thought.
Regards
--
Adrian Hey
