Re: Closures versus objects

Specifically, the very moment a "computer guy/gal" uses the phrase "I  
just want to express one with the other", we need to question what  
this means considering the fact that every computational mechanism  
can be translated into every other one if we allow the entire class  
of functions as "translators" or "expressors". So my paper suggests  
one natural way to restrict the class of translations. I call it  
"natural" because it was implicitly used starting with Landin. I also  
think Guy and Gerry used it in the Lambda series. One could imagine  
other classes of translations but with the exception of Riecke (MIT)  
nobody seems to have studied this issue much and found useful results.

-- Matthias




On Feb 15, 2007, at 6:47 PM, Joe Marshall wrote:

> Felleisen argues that the relevent measure is `macro- 
> expressability' in
>
> @incollection{ felleisen90expressive,
>    author = "Matthias Felleisen",
>    title = "On the Expressive Power of Programming Languages",
>    booktitle = "{ESOP} '90 3rd European Symposium on Programming,
> Copenhagen, Denmark",
>    volume = "432",
>    publisher = "Springer-Verlag",
>    address = "New York, N.Y.",
>    editor = "N. Jones",
>    pages = "134-151",
>    year = "1990",
>    url = "citeseer.ist.psu.edu/felleisen90expressive.html" }
>
> He points out that any turning-complete language can emulate any  
> other,
> so perhaps a more useful measure of expressiveness is whether you can
> directly implement a language feature in another language with only  
> local
> transformations.
>
> On 2/15/07, Robbert Haarman <[email protected]> wrote:
>> On Thu, Feb 15, 2007 at 10:39:14PM +0100, Pascal Costanza wrote:
>> >
>> > As soon as your language is Turing-complete, anything you add is
>> > redundant. Language features are always only about convenience.
>>
>> I contest that. In a theoretical world where only programs and/or  
>> values
>> exist, any Turing-complete language may be equivalent to any other
>> Turing-complete language. However, in a practical world, where things
>> besides programs and values exist, there are real differences in what
>> languages can and can't do which have nothing to do with
>> Turing-completeness.
>>
>> For example, to drive the PC's floppy drive controller, you need  
>> access
>> to I/O ports. If your language does not provide such access, you  
>> can't
>> drive the FDC from that language, whether the language is
>>
>> Turing-complete or not.
>>
>> Even when language features are only about convenience (which I  
>> believe
>> is the case with closures vs. objects), they make a difference. For
>> example, I think available language features have a great  
>> influence of
>> what programming paradigms will be common. I also think most  
>> people on
>> this list will agree with me that different paradigms are suitable  
>> for
>> different problems. This means that languages in which certain  
>> paradigms
>> cannot be expressed elegantly cannot be used to solve certain  
>> problems
>> elegantly. This can have very real implications, such as these  
>> problems
>> not being solved or the programs that purport to solve them being
>> unreliable.
>>
>> To put the above more bluntly and concisely: I think Turing- 
>> completeness
>> is overrated, and that designing a language so that only one or a few
>> paradigms can be elegantly expressed in it is a mistake.
>>
>> Regards,
>>
>> Bob
>>
>> --
>> That that is is that that is not not, that is, not that that is not.
>>
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.5 (GNU/Linux)
>>
>> iD8DBQFF1O6Lfb9wcmD+WN4RAksBAKCs7celALHKE37xyVJl/cBYlKqi6wCcD8Y3
>> kltPkj9NzTpzHqlAXUSycRk=
>> =ClAu
>> -----END PGP SIGNATURE-----
>>
>>
>
>
> -- 
> ~jrm
>