Darren New wrote:
> Technically, I would think you could have a curried function in a 
> language with named parameters pretty easily.

Yeah, I don't see why not. It's only a shortcut for creating a closure...

>>> Lambda expressions are darned convenient. I used them in my little 
>>> FFT toy app:
>>>
>>> RealInput.Data = GenerateWave(x => cos((Math.Pi*2*x)/(DataLen-1)));
>>
>> They're also damned useful when you want to curry a function:
>>   bar = foo (...my random lambda function that I only just here...)
> 
> That's where they're used in C#.

I didn't think C# had curried functions like my example.

> This is how the mechanisms for 
> querying SQL from C# work - you can write something like
>   db.table["customers"].select(x => x.Name > "Henry")
> and the "select()" function takes the AST describing that condition, 
> translates it to SQL, and sends it to the database.

Lisp would be proud.

Does this transformation happen at compile-time or runtime?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
>    class Thing {
>      static public int pdq(float y) { ... }
>      public abc(float z) { return (int) (z*this.stuff); }
>      int stuff;
>      Thing() { stuff = 28; }
>    }

>    Thing o = new Thing();
>    delegate int xyz(float x);
>    xyz = Thing.pdq;
>    xyz += o.abc;
>    xyz(27.3);  //  I think this will return the result of calling o.abc(27.3)

> Pretty handy.

  What if you want to call the function (through the pointer) for different
objects? I mean like you would write in C++:

    Object obj1, obj2;
    obj1.*funcPtr(param);
    obj2.*funcPtr(param);

  The same member function is called, but for different objects. (Thus if
the function in question eg. changes the state of the object, it happens
to the specified object.)

  Curiously, you can even have pointers-to-member-variables in C++, and you
can then dereference the pointer on a per-object basis. That gets pretty
confusing pretty quick.

-- 
                                                          - Warp

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Transparently.

> e.g.

> delegate void myDel(int x);

> class SomeClass
> {
>    public int myValue;

>    public void DoInstanceStuff(int x)
>    {
>      myValue = x;
>    }

>    public static void Main()
>    {
>      SomeClass c = new SomeClass();

>      myDel d = c.DoInstanceStuff

>      d(6); // this sets c.myValue to 6;

>    }
> }

  So you can't use the same function delegate for calling a member
function of two different objects?

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Warp escreveu:
> >   The fact is: If a programming language supports types, if it also
> > supports abstract user-defined types, it becomes an order of magnitude
> > more expressive and useful. And abstract user-defined types are objects
> > (in the OO sense).

> But that's within a function composition environment.

  Ah, so we avoid being related to the dreaded Object-Oriented Programming
(vade retro) by using different terminology for the same things. Then we
can write long lists of reasons why *our* terms do not *really* mean the
same things as the equivalent OOP terms.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
>> Transparently.
> 
>> e.g.
> 
>> delegate void myDel(int x);
> 
>> class SomeClass
>> {
>>    public int myValue;
> 
>>    public void DoInstanceStuff(int x)
>>    {
>>      myValue = x;
>>    }
> 
>>    public static void Main()
>>    {
>>      SomeClass c = new SomeClass();
> 
>>      myDel d = c.DoInstanceStuff
> 
>>      d(6); // this sets c.myValue to 6;
> 
>>    }
>> }
> 
>   So you can't use the same function delegate for calling a member
> function of two different objects?
> 

No, I don't think you can. The closest you could get would be something 
like a multicast delegate. But, then you really cannot get a return value.
-- 
~Mike

Post a reply to this message

Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> But that's within a function composition environment.
> 
>   Ah, so we avoid being related to the dreaded Object-Oriented Programming
> (vade retro) by using different terminology for the same things. Then we
> can write long lists of reasons why *our* terms do not *really* mean the
> same things as the equivalent OOP terms.

Not that.  I have no problem calling ADTs objects or parametrized 
regions of code subroutines, functions, procedures, methods or whatever, 
as long as it's not within a OO framework.  I like functional 
programming fluidity and lack of bureaucracy.

Post a reply to this message

Orchid XP v8 wrote:

>> This is how the mechanisms for querying SQL from C# work - you can 
>> write something like
>>   db.table["customers"].select(x => x.Name > "Henry")
>> and the "select()" function takes the AST describing that condition, 
>> translates it to SQL, and sends it to the database.
> 
> Lisp would be proud.
> 
> Does this transformation happen at compile-time or runtime?
> 

Runtime, I believe. The select extension function for the IQueryable 
interface takes an expression as its parameter. That expression object 
is whats used to build the expression tree. LinqToSQL uses that to build 
the SQL query.

-- 
~Mike

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Not that.  I have no problem calling ADTs objects or parametrized 
> regions of code subroutines, functions, procedures, methods or whatever, 
> as long as it's not within a OO framework.  I like functional 
> programming fluidity and lack of bureaucracy.

  Well, I usually prefer encapsulation and abstraction over fancy
one-liners.

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> Not that.  I have no problem calling ADTs objects or parametrized 
>> regions of code subroutines, functions, procedures, methods or whatever, 
>> as long as it's not within a OO framework.  I like functional 
>> programming fluidity and lack of bureaucracy.
> 
>   Well, I usually prefer encapsulation and abstraction over fancy
> one-liners.

encapsulation and abstraction are conserved, thanks. :)

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Warp escreveu:
> > nemesis <nam### [at] gmailcom> wrote:
> >> Not that.  I have no problem calling ADTs objects or parametrized 
> >> regions of code subroutines, functions, procedures, methods or whatever, 
> >> as long as it's not within a OO framework.  I like functional 
> >> programming fluidity and lack of bureaucracy.
> > 
> >   Well, I usually prefer encapsulation and abstraction over fancy
> > one-liners.

> encapsulation and abstraction are conserved, thanks. :)

  So you take what's great about OOP, rename it, and then say you hate OOP
and that it sucks, and that your own version is so much better.

-- 
                                                          - Warp

Post a reply to this message