Received: by 10.66.85.166 with SMTP id i6mr158468paz.13.1350633421933;
        Fri, 19 Oct 2012 00:57:01 -0700 (PDT)
Path: 6ni5918pbd.1!nntp.google.com!news.glorb.com!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
From: torb...@diku.dk (Torben Ægidius Mogensen)
Newsgroups: comp.lang.functional
Subject: Re: ML: psychological basis of language ranking?
References: <k5jmhr$gq1$1@dont-email.me>
Date: Fri, 19 Oct 2012 09:58:34 +0200
Message-ID: <7z6266ao5x.fsf@ask.diku.dk>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
Cancel-Lock: sha1:B67/g83l/gVY2y9476BEawIfoig=
MIME-Version: 1.0
Lines: 75
Organization: SunSITE.dk - Supporting Open source
NNTP-Posting-Host: 130.225.96.225
X-Trace: news.sunsite.dk DXC=XO;6h@QI@_I8R0D<PWbV?JYSB=nbEKnkKcWN^LcTk:7FeA0c^o`FO0DNW[cF@L;gDGF5\^6VX=jYDc0FE@hl?W;GHCj7mRnGKVH
X-Complaints-To: staff@sunsite.dk
Content-Type: text/plain; charset=us-ascii

Avoid9...@gmail.com writes:

> What does Harper mean?
> I'll try to interpret this first/easier one, my self:
>   ]Object-oriented programming is eliminated entirely from the
>   ]introductory curriculum, because it is both anti-modular and
>   ]anti-parallel by its very nature, and hence unsuitable for a modern
>   ]CS curriculum. 
> Does he mean, that since the essence of OO is that objects
> are defined [hence dependant on] by their ancestor, knowledge
> about an object can't be decoupled from knowledge about its
> ancestors?

I don't think so.  Objects are anti-paralllel because the fundamental
operation on modules is reading and updating storage local to the
object. I'm not sure what in particular makes him call them
anti-modular, but it might be for much the same reason: If there is
local mutable state in objects, you can't compose them freely, as a use
of the object in one place can affect another use of the same object in
another place in a way that you can't predict from its interface.

> Yes, for me, the freedon to NOT be-concerned-about 
> side issues is a MASSIVE advantage for any programming
> system.  And the ability to 'pipe/data-transform' sequentially
> like forth, and at tested/confirmed stageN not to need to
> be-concerned-about stageN-2. 
>
> Does ML support such a [concatenative] style?

If I understand you correctly, it does.  Function composition is natural
and easy in ML.


> ====> Then in
> http://existentialtype.wordpress.com/tag/type-theory/
> he writes: [in my simplified non-LaTex notation]
>
>>In languages we have the fundamental concept of a typing judgement, written
>>    x1:A1,...xn:An => M:A
>> stating that M is an expression of type A involving variables xi of type Ai.
>
> That's OK.
>>
>>A typing judgement must satisfy the following basic structural properties:
>>  x:A  =>  x:A
>>  
>>  y:B   =>  N:C     x:A  => M:B
>>-----------------------
>>        x:A  =>  [M/y]N:C
>>        
>> We may think of the variables as names for "libraries", in which
>>   case the first states that we may use any library we wish, and the
>>   second states closure under "linking" (as in the Unix tool ld or its
>>   relatives), with [M/x]N being the result of linking x in N to the
>>   library M .  
>
> Let's try to unpick that, in steps:
>  y:B   =>  N:C
> means N is an expression of type C involving variable y of type B
>     x:A  =>  M:B
> means M is an expression of type B involving variable x of type A
>
> By `"linking" (as in the Unix tool ld)`, does he mean 'replace the
> expression, with the code-which-implements it'?
>
> What is his main point?

The main point is that types act as contracts: If you replace a variable
of type B with an expression of type B, this will not yield typpe errors
and the type of the surrounding expression should not change by this
exchange.  Basically, An expression of type B has the same type in every
context (assuming free variables, in this case x, do not change their
type in the different contexts).

	Torben