why () is () and [] is [] work in other way?

[rusi]

On Apr 26, 7:44 pm, Adam Skutt <ask... at gmail.com> wrote:
> On Apr 26, 10:18 am, rusi <rustompm... at gmail.com> wrote:
>
> > On Apr 26, 4:42 pm, Adam Skutt <ask... at gmail.com> wrote:
>
> > > In a mathematical sense, you're saying that given f(x) = x+2, using
> > > f(x) is somehow more "direct" (whatever the hell that even means) than
> > > using 'x+2'.  That's just not true.  We freely and openly interchange
> > > them all the time doing mathematics.  Programming is no different.
>
> > If f(x) and x+2 are freely interchangeable then you have referential
> > transparency, a property that only purely functional languages have.
> > In python:
>
> I think you misunderstood what I was trying to explain.  Steven is
> trying to claim that there's some sort of meaningful difference
> between calling an operation/algorithm/function by some name versus
> handing out its definition.  I was merely pointing out that we
> routinely substitute the two when it is appropriate to do so.
>
> My apologies if you somehow took that to mean that I was implying
> there was referential transparency here.  I couldn't think of a better
> example for what I was trying to say.
>
> Adam

And my apologies... I forgot to state my main point:
Programmer accessible object identity is the principal impediment to
referential transparency.
In a functional language one can bind a name to a value -- period.
There is nothing more essence-ial -- its platonic id -- to the name
than that and so the whole can of worms connected with object identity
remains sealed within the language implementation.