On Sun, 10 Feb 2008 00:55:54 GMT, stephen@[EMAIL PROTECTED]
(Stephen
J. Bevan) wrote:
>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
Sorry, it wasn't.
>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.
Having just discovered MPS I can't say what it can or can't handle
other than, by inclusion, it can obviously handle Dylan's specific
needs.
Despite their close relatedness, Lisp and Scheme and Dylan all have
somewhat different memory usage characteristics. Scheme tends to cons
more quickly than Lisp. Lisp itself has wide variation - CLOS
programs tend to cons much less and less quickly than regular Lisp
programs. Dylan, being an object oriented Scheme, probably falls
somewhere between Scheme and Lisp/CLOS. Dylan's objects require
finalization support in the GC which neither Lisp nor Scheme is
required to provide.
[In fairness, most Lisps and some Schemes do provide finalization in
support of their own object frameworks, but the languages have no
special support for OOP.]
>>>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 wasn't even thinking about MPS ... I was simply answering your
question about what factors affect GC implementations. There are some
additional bit players but the main one are allocation rate, mortality
rate, and mutable vs immutable data.
>> 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.
That's true, but you can develop an average profile for a particular
benchmark across implementations of the same language and relate it to
the same benchmark coded in a different language. Extending such
benchmarks to families of related languages gets fuzzier but you can
still make some general comparisons.
I'm excluding Lisp on the basis that it is multi-paridigm and not
primarily functional. Based on usage, I would consider the ML family
of languages the "average" FPL. I know there are also relatively
large numbers of Miranda, Erlang, and now Haskell users, but I think
the number of users of ML variants is greater than the others put
together.
George
--
for email reply remove "/" from address
|
