George Neuner <gneuner2/@[EMAIL PROTECTED]
> writes:
> On Sat, 09 Feb 2008 04:15:51 GMT, stephen@[EMAIL PROTECTED]
(Stephen
> J. Bevan) wrote:
>
>>George Neuner <gneuner2/@[EMAIL PROTECTED]
> writes:
>>
>>> However, Dylan is still a Scheme is still a Lisp.
>>
>>Aren't all functional languages a Lisp then?
>
> Not really.
[ history lesson deleted ]
I assumed the GC context to the question was clear but since since
both you and Philippa didn't relate the question to GC at all and
though I was didn't know the history of Dylan or functional languages
I'll rephrase the question :-
If MPS was used in Dylan but according to you Dylan is a Lisp and
thus MPS was effectively used in a Lisp, then aren't all functional
languages a Lisp when it comes to the question of whether MPS can be
used in them or not?
If you disagreed then I was expecting some specific detail of a
functional language that would mean that MPS would not obviously be
able to handle it.
>>Or is there something
>>different about some functional languages (Haskell?) which makes their
>>GC requirements different?
>
> The functional languages, as a group, average higher allocation and
> infant mortality rates than is typical for Lisp - it's important to
> focus effort on allocation speed and on efficiently cleaning the
> nursery in an FPL (Lisp also benefits from these things, just to a
> lesser degree).
>
> Also mutable vs immutable data makes a huge difference in the
> complexity of the collector if GC is intended to be interleaved or
> concurrent with the program.
Indeed but you originally thought that MPS has been used in ML which
has a lot more immutable data than Lisp. Thus to ask whether MPS can
be used in a language other than Lisp or ML and then bring up
immutability you must be thinking of a language that has even more
immutable data than ML and/or is somehow more threaded than Harlequin
Dylan which MPS as used in and which supported threads and Dylan's
immutable types.
> I don't know specifically about Haskell, but I would imagine that it
> has slightly higher rates of closure creation and disposal than the
> average FPL.
That would depend on what an "average FPL" was. Back when SML/NJ and
MLWorks were "competitors" for SML marketshare, SML/NJ's allocation
rate was, by design, dramatically higher than MLWorks. Same language,
radically different allocation rates.
|
