clipka <ano### [at] anonymousorg> wrote:
> >    An object-oriented language is a programming language that supports
> > the necessary features for OOP natively.

> That would qualify Assembler and C as object-oriented: They both 
> natively support /all/ features that are really /necessary/ for OOP 
> (actually for /every/ concept commonly associated with OOP).

  I can't fathom how you are understanding my sentence as meaning the
*exact opposite* of what it's saying.

  Assembler and C are precisely *not* OOP languages because they do *not*
have any kind of native support for OOP features. If you want any kind of
object-oriented programming, you'll have to hack those features manually
because the languages themselves offer no support whatsoever.

> You /can/ do OOP with plain old ANSI C.

  So what? That doesn't make it an OOP language.

> I'd say, an object-oriented language is a language that provides 
> syntactic sugar specifically for OO concepts. Syntactic sugar isn't a 
> /necessary/ feature for OOP though.

  I said in my post "do not confuse object-oriented programming with an
object-oriented programming language", and you are doing exactly that.

-- 
                                                          - Warp

Post a reply to this message

Le 2012-04-25 04:09, Invisible a écrit :
> On 25/04/2012 06:13 AM, Darren New wrote:
>> On 4/23/2012 3:19, Invisible wrote:
>>> ∃ i ∈ S: ∀ x ∈ S, i # x = x # i = x.
>>
>> I must say it cracks me up that you type things like this and also bitch
>> about HTML entities not being part of XML.
>
> How do you think I got access to the symbols in the first place? I wrote
> an HTML document with the right entities in it, loaded it into Firefox
> and I was then able to copy and paste them into Thunderbird.
>
> Interestingly, when you put non-ASCII characters into an NNTP post, it
> actually works. When you write them into an XML document, it fails
> horribly. (In fact, not even non-ASCII. The £ symbol tends to go wrong
> too...)

That's because Thunderbird changed them to UTF-8, because you told it to 
do so in the account options dialog box.

...

Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

...

On 4/23/2012 3:19, Invisible wrote:
 > =E2=88=83 i =E2=88=88 S: =E2=88=80 x =E2=88=88 S, i # x =3D x # i =3D x=
=2E


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>>    ∃ i ∈ S: ∀ x ∈ S, i # x = x # i = x.
>
> Hey, not only you added identity element, but you seems to imply also
> (but not really) that its also commutative:
>
> ∀ x ∈ S, ∀ y ∈ S, x # y = y # x.
>
> So please be more careful for my poor brain and write instead:
>
> ∃ i ∈ S: ∀ x ∈ S, i # x = x and x # i = x.
>
> There is commutativity for the identity element, but it is not needed to
> be commutative.

A monoid is /defined as/ having a two-sided identity.

Note that it is possible to have more than one left-identity, OR to have 
more than one right-identity. But it is impossible to have a 
left-identity and a distinct right-identity.

Suppose that

   ∃ i ∈ S: ∀ x ∈ S, i # x = x
   ∃ j ∈ S: ∀ x ∈ S, x # j = x

are the left and right identities of #. Now consider the term i#j. By 
the first equation, i#j=j. By the second equation i#j=i. Thus we have 
that i = j.

> Your definition of inverse element once again seems to imply general
> commutativity, it is not needed.

Again, a group is /defined as/ having two-sided inverses.

If you wish to split hairs, you don't actually need to /insist/ that the 
inverses by double-sided; the associativity of # and the existence of a 
two-sided inverse i already necessarily implies this fact:

Consider the term

   x # y # x

where y is the left-inverse of x. By that assumption, we have

   (x # y) # x = i # x

and by the definition of i as the two-sided identity, we have

   (x # y) # x = i # x = x

By the assumption of associativity, we have that

   (x # y) # x = x # (y # x)

It immediately follows that y # x must be the identity, and hence that y 
is ALSO the right-inverse of x. QED.

> (I like to think about the Quaternion group (non abelian group of order
> 8): 1&  -1 are their own inverse, but inverse of i,j,k are same negative
> (-i, -j, -k))

OK, so 1 is the identity element, -i is the inverse of i, -j is the 
inverse of j, and -k is the inverse of k.

> Yes, -i.i = i.-i = 1
> but i.j = -j.i = k

That is true - but irrelevant. You just proved that the group is 
non-Abelian. We know that. We're discussing the /inverses/ though, and 
if you look, we have:

   i . -i = 1 = -i . i
   j . -j = 1 = -j . j
   k . -k = 1 = -k . k

In other words, -i is the TWO-SIDED inverse of i, and so on and so forth 
- as I originally asserted.

Every term commutes with the identity and with its own inverse. It might 
not commute with anything else, but it does commute with these two 
special elements.

Post a reply to this message

On 22-4-2012 12:40, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>>> For instance,
>>> I still don't understand what currying *really* is about, and every time
>>> I try to suggest "is like this?" the answer is "not really".
>
>> 1. You can take a 5-argument function, pass it 2 argument, and get a
>> 3-argument function as the result.
>
>    But that's the thing: It sounds so trivial as to defy sense. Why give
> a particular name to such a trivial thing? It's like calling the act of
> taking a 3-dimensional vector and expanding it to a 4-dimensional one
> "potatoing", or taking two integers and adding them together "bananaing",
> or taking a class and adding another class as its member "orangeing".
> Why give an obscure name to such a trivial operation?
>
>    But then when one starts asking questions like "so it's like giving
> default values to function parameters?" or "so it's like writing another
> function with less parameters that calls the first function by giving it
> some default values as the rest of the parameters?", the answer is something
> like "not really".

My answers to why currying is important is that
- if you have currying, you have function application. if you have a one 
input function and you supply that input you reduce it to a zero 
argument function a.k.a. a constant. If you think about it that way the 
distinction between a value and a function gets blurred.
- I think that one of the main reasons to give it a name is that when 
the concept was invented you suddenly had (non-exotic) functions that 
could take functions as argument and return yet another function. In 
short it is when functions transformed from recipes to objects.

When you have done OO languages for some time you might not see the 
point anymore, that does not mean that at one point in time you made the 
mental transition yourself.


-- 
tip: do not run in an unknown place when it is too dark to see the 
floor, unless you prefer to not use uppercase.

Post a reply to this message

Warp escreveu:
> clipka <ano### [at] anonymousorg> wrote:
>> So yes: Currying *is* like writing a function that takes fewer 
>> arguments, calling the original one and supplying (unchangeable) 
>> defaults for the missing arguments.
> 
>   I think that the difference is that the new function is not static,
> but it's generated dynamically. (In other words, what you end up is a
> new function which fixes some of the parameters of the original function,
> but the values to which they are fixed is determined at runtime rather
> than at compile time.)
> 
>   This means, if I understand correctly, that you could for example create
> such functions in a loop (or, as we are talking about functional languages,
> in a recursive manner), which is quite difficult to achieve with static,
> compile-time functions. (I suppose you could try to emulate this in a
> statically typed language with no lambda functions, but you would need
> some kind of stack or something where the fixed parameter values are
> stored.)
> 
>   There are probably even deeper implications.

currying comes from Haskell Curry, the mathematician behind many further 
lambda calculus concepts.

Here's the thing about the lambda calculus, which is at the kernel of 
haskell the language:  all the functions are one-argument functions that 
return other one-argument functions.  So, multiple argument functions 
are actually just syntatic sugar for convenience.  And yes, clearly 
syntatic sugar is a good thing, as any competent C++ template writer can 
attest.

Surely writing a function and letting the compiler handle all the 
partial applications is much saner than writing yourself functions for 
each possible partial application case.  And no, I don't think in 
haskell such functions are dynamically generated.  Like I said, the 
concept of one-argument functions is at the very heart of haskell:  the 
compiler breaks all functions down into one-argument functions, at 
compile time.

Then again, in languages with default and keyword arguments you do not 
need to worry about that, only to remember the argument names.  Argument 
position, names or order, though, can still shoot everyone in the foot.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Am 25.04.2012 10:07, schrieb Invisible:
> On 25/04/2012 06:08 AM, Darren New wrote:
>> On 4/23/2012 1:05, Invisible wrote:
>>>> There are lots of languages that let you can pass a function as an
>>>> argument.
>>>
>>> Heh. I bet most of them are scripting languages though. :-P
>>
>> Not really. Arguably, even C allows it, C++, C# allows a delegate which
>> is essentially the same thing, and yes, bunches of interpreted languages.
>
> C and C++ have function pointers. It's dubious whether functions are
> "first class", but certainly you can pass them as arguments.
>
> C# presumably allows /everything/.
>
> Java allows you to use the reflection API to create an object that
> represents a function method, and to invoke that method. Alternatively
> you can use anonymous inner classes. (The fact that this feature even
> /exists/ tells you how badly Java programmers want anonymous functions.)
>
> Pascal? Forget it.

Turbo Pascal? Definitely yes, as I mentioned before!

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Here's the thing about the lambda calculus, which is at the kernel of 
> haskell the language:  all the functions are one-argument functions that 
> return other one-argument functions.  So, multiple argument functions 
> are actually just syntatic sugar for convenience.

  But what's the advantage in having only one-argument functions?

-- 
                                                          - Warp

Post a reply to this message

>> Pascal? Forget it.
>
> Turbo Pascal? Definitely yes, as I mentioned before!

OK, but that's not really the classic Pascal of old.

The same probably goes for Delphi, which [I gather] is a further 
extension of Turbo Pascal.

In a similar was, AMOS BASIC has local variables, named functions and 
procedures, separate compilation, and a whole chock-load of features. In 
fact, so many features that it hardly counts as "BASIC" any more; it's 
more like a brand new language with a superficial resemblance to BASIC...

Post a reply to this message

On 25/04/2012 09:01 PM, Warp wrote:
> nemesis<nam### [at] gmailcom>  wrote:
>> Here's the thing about the lambda calculus, which is at the kernel of
>> haskell the language:  all the functions are one-argument functions that
>> return other one-argument functions.  So, multiple argument functions
>> are actually just syntatic sugar for convenience.
>
>    But what's the advantage in having only one-argument functions?

If you're writing a mathematical theory about which computations are 
possible, then only having to worry about 1-arg functions makes the 
theory simpler. That's why the lambda calculus does it that way.

If you're trying to write a real program to run on a real computer, 
that's another matter.

It's useful to be able to quickly throw together a new function by just 
writing a partial call to an existing one. The easiest way to implement 
that is to consider every function to be a 1-arg function.

Aside from a couple of other conveniences, it also allows you to process 
functions of variable numbers of arguments in a uniform way: Keep adding 
arguments, one at a time, until it's full.

There's nothing deeply fundamental or sacred about 1-arg functions. They 
just have a couple of useful properties, that's all.

Post a reply to this message

Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> Here's the thing about the lambda calculus, which is at the kernel of 
>> haskell the language:  all the functions are one-argument functions that 
>> return other one-argument functions.  So, multiple argument functions 
>> are actually just syntatic sugar for convenience.
> 
>   But what's the advantage in having only one-argument functions?

seemingly, automatic currying.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message