• Russell Lewis (20/20) Oct 03 2002 Another obscure-yet-practical idea I ran across writing my program. I
• Mark Evans (5/5) Oct 03 2002 Mathematica permits anonymous functions in its Map calls (iterators). T...
• Sean L. Palmer (15/35) Oct 03 2002 I like it. I could even live with the anon keyword. I still don't like...
• Russell Lewis (9/25) Oct 03 2002 Yes, that's the kind of thing I'm thinking of. I was concerned, though,...
• Sean L. Palmer (10/35) Oct 04 2002 It's the same old void (*callback)(Bar)[] typespec issues. Anything tha...
• Mike Wynn (97/139) Oct 04 2002 I belive that the function pointer syntax should be like the delegate sy...
• Mac Reiter (10/30) Oct 07 2002 Oh, I am all about anonymous functions. Once you start talking about _R...
• Walter (5/25) Oct 20 2002 Great idea! I've been convinced for some time that anonymous functions a...
• Mike Wynn (8/40) Oct 20 2002 will you been about to do ...
• Russ Lewis (7/7) Oct 20 2002 I don't see why you couldn't. That certainly was the kind of things I w...
• Walter (4/9) Oct 20 2002 Yes, but the exact syntax is an open question. Haven't thought too much
• Sean L. Palmer (3/3) Oct 20 2002 Do either Walter or Burton think that D is sufficiently progressed to th...
• Burton Radons (4/6) Oct 20 2002 It is and would be quite a lot simpler than the current compiler. The
• Walter (3/6) Oct 24 2002 Please expand on this, so I can address it.
• Walter (3/5) Oct 24 2002 Yes it has.

Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:

Another obscure-yet-practical idea I ran across writing my program.  I 
have to code horde of little callback functions.  It would be nice to be 
able to declare them inline.  The current D code works something like this:

   struct Foo {
     void (*callback)(Bar);
   }

   Foo[] array;

   void Callback_0(Bar arg) {...};
   array[0].callback = &Callback_0;
   void Callback_1(Bar arg) {...};
   array[1].callback = &Callback_1;
   void Callback_2(Bar arg) {...};
   array[2].callback = &Callback_2;

It would be a lot nicer to declare those functions inline.  For 
consistency with my anon-struct suggestion, I'll suggest we use the 
'anon' keyword here, too:

   array[0].callback = void anon(Bar arg) {...}
   array[1].callback = void anon(Bar arg) {...}
   array[2].callback = void anon(Bar arg) {...}

Thoughts, anyone?

Mark Evans <Mark_member pathlink.com> writes:

Mathematica permits anonymous functions in its Map calls (iterators).  They are
often very, very useful.

I am not sure that D can accommodate them or that it should.  I suppose when D
has iterators, that will be the time.

Mark

"Sean L. Palmer" <seanpalmer directvinternet.com> writes:

I like it.  I could even live with the anon keyword.  I still don't like C
declaration syntax.

I want to be able to do this:

class Bar;
void (*callback)(Bar)[] array;

array = { void (Bar arg) { fee(); }, void (Bar arg) { fie(); }, void (Bar
arg) { foe(); }, void (Bar arg) { fum(); } };

Or even:

typedef void (*callback)(Bar) callbacktype;
callbacktype[] array = { callbacktype { fee(); }, callbacktype { fie(); },
callbacktype { foe(); }, callbacktype { fum(); } };

Sean

"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D9D1482.6000608 deming-os.org...
 Another obscure-yet-practical idea I ran across writing my program.  I
 have to code horde of little callback functions.  It would be nice to be
 able to declare them inline.  The current D code works something like

this:
    struct Foo {
      void (*callback)(Bar);
    }

    Foo[] array;

    void Callback_0(Bar arg) {...};
    array[0].callback = &Callback_0;
    void Callback_1(Bar arg) {...};
    array[1].callback = &Callback_1;
    void Callback_2(Bar arg) {...};
    array[2].callback = &Callback_2;

 It would be a lot nicer to declare those functions inline.  For
 consistency with my anon-struct suggestion, I'll suggest we use the
 'anon' keyword here, too:

    array[0].callback = void anon(Bar arg) {...}
    array[1].callback = void anon(Bar arg) {...}
    array[2].callback = void anon(Bar arg) {...}

 Thoughts, anyone?

Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:

Sean L. Palmer wrote:
 I like it.  I could even live with the anon keyword.  I still don't like C
 declaration syntax.
 
 I want to be able to do this:
 
 class Bar;
 void (*callback)(Bar)[] array;
 
 array = { void (Bar arg) { fee(); }, void (Bar arg) { fie(); }, void (Bar
 arg) { foe(); }, void (Bar arg) { fum(); } };
 
 Or even:
 
 typedef void (*callback)(Bar) callbacktype;
 callbacktype[] array = { callbacktype { fee(); }, callbacktype { fie(); },
 callbacktype { foe(); }, callbacktype { fum(); } };

Yes, that's the kind of thing I'm thinking of.  I was concerned, though, 
that the syntax
   <type> (<arglist>) { <code> }
might end up with parsing ambiguities.  I haven't looked at it in 
detail, so maybe I'm wrong.  I just thought that an 'anon' keyword would 
make it very easy to both read and to parse.

Can you clarify what you mean by you "still don't like C declaration 
syntax"?

"Sean L. Palmer" <seanpalmer directvinternet.com> writes:

It's the same old void (*callback)(Bar)[] typespec issues.  Anything that I
think would fix it would also make it seem very non-C flavored.

Parsing ambiguities can be dealt with as they arise.  The exact syntax isn't
as important as the intention and ease of coding.

Sean

"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D9D2FF1.5070000 deming-os.org...
 Sean L. Palmer wrote:
 I like it.  I could even live with the anon keyword.  I still don't like


C
 declaration syntax.

 I want to be able to do this:

 class Bar;
 void (*callback)(Bar)[] array;

 array = { void (Bar arg) { fee(); }, void (Bar arg) { fie(); }, void


(Bar
 arg) { foe(); }, void (Bar arg) { fum(); } };

 Or even:

 typedef void (*callback)(Bar) callbacktype;
 callbacktype[] array = { callbacktype { fee(); }, callbacktype {


fie(); },
 callbacktype { foe(); }, callbacktype { fum(); } };

 Yes, that's the kind of thing I'm thinking of.  I was concerned, though,
 that the syntax
    <type> (<arglist>) { <code> }
 might end up with parsing ambiguities.  I haven't looked at it in
 detail, so maybe I'm wrong.  I just thought that an 'anon' keyword would
 make it very easy to both read and to parse.

 Can you clarify what you mean by you "still don't like C declaration
 syntax"?

"Mike Wynn" <mike.wynn l8night.co.uk> writes:

I belive that the function pointer syntax should be like the delegate syntax
i..e. `void function(Bar)`
so to return one `void function(Bar) myFunc( ... ) { ... return ... ; }`
to alias/typedef `alias void function(Bar) myCallback;`
(I also dislike the extra '&' require on delegates and function pointers)
the code
int myFunc( int a, int b ) { ... }
myFunc should be of type int function(int,int);
and
class A {
    int myMethod( int a, int b ) { ... }
}
with
A a = new A();
then `a.myMethod` should be of type int delegate(int,int)
rather than &a.myMethod being of type int delegate(int,int)

you should be able to do the following;

alias void function(Bar) Foo;
void Callback_0(Bar arg) {...};
void Callback_1(Bar arg) {...};
void Callback_2(Bar arg) {...};
Foo[] array = [ Callback_0, Callback_1, Callback_2 ]

or even more "perl `sub` like" :
Foo[] array = [
    int function( Bar arg){ ... },
    int function( Bar arg){ ... },
    int function( Bar arg){ ... }
]

because all of these are determinable at compiler time.

I also feel that real "closures" types should be an allowed as types as a
mix between Java anon classes and D delegates;

alias int delegate( int ) mySub;

mySub getSumFunc( int toAdd )
{
    return sub(int delgate( int num )){ return toAdd+num; }
}

which is basically converted into

typedef int delegate( int ) mySub;
class Anon000 {
    int toAdd;
    this( int toAdd0 ) { toAdd = toAdd0; }
    int getSumFunc( int num ) { return toAdd+num; }
}

mySub getSumFunc( int toAdd )
{
    return (new Anon000(toAdd)).getSumFunc;
}

they have to be delegates not function pointers because they contain
'context'
 but would allow a function pointer to be converted to a delegate
i.e.
int myFunc( int a ) { ... }
int delegate( int ) b = cast(int delegate( int ))myFunc;
gets converted to
class Anon001 {
    int function( int ) toCall;
    this( int function( int ) toCall0 ) { toCall = toCall0; }
    int myFunc( int a ) { return toCall( a ); }
}
int delegate( int ) b = new Anon001(myFunc).myFunc;

due to the Java interface semantics you can use anon classes to perform a
function close to that of a closure or delegate. but neither has the power
of Perl sub or scheme lamda.

before you burn this down in flames, I think so should consider, Is D a
replacement for C along the lines of IMP with C syntax, GC and objects
ideally suited to medium size fast programs, modules or libraries, or is D a
replacement for C++/Java/Perl/Delphi/VB and designed for large applications
with features to allow the programmer  to write code that is the task they
want performed, without having to extensivly consider issues such as
resource management, with features to allow library coder to put in place
checks and asserts that allow them to detect if the the other coder and user
of their code are conforming to the designed interface.
Perl may have been beaten within an inch of its life with the ugly stick but
Larry Wall make some very astute observations about programmers, and Perl
have been around for 14 years, perl 5 about 8 and is popular and capable of
being used to write large systems so it must be doing something right.
I personally loathed Perl until I had to use it for a CGI backend to an MFC
client to communicate to a Database over HTTP, the original programmer left
the project an I was the only other person who understood the comms layer.
when I returned to the C++ side of the project I found a lot of the features
I took for granted in Perl where lacking from C++, seemingly without reason,
like 'redo'.
some of Perl syntax also seems odd at first but once you are used to it, it
can make code more readable (not a feature Perl is known for, but I consider
describing it as a "write only language" is a reflection on Perl programmers
and not the language itself)
for instance in C the if clause is:
'if' <cond> (<statment> |<block>) ['else' (<statement>|<block>)]
in Perl its
('if'|'unless') <cond>  <block> ['elsif' <cond>  <block>]* ['else' <block>]
or
<statement> ('if'|'unless') <cond> ';'
in both cases <cond> ::= '(' <expr> ')'
allowing the more 'english' `return 0 if ( a < 0 );
but I'm flying way off topic!

"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:anj962$2jk5$1 digitaldaemon.com...
 I like it.  I could even live with the anon keyword.  I still don't like C
 declaration syntax.

 I want to be able to do this:

 class Bar;
 void (*callback)(Bar)[] array;

 array = { void (Bar arg) { fee(); }, void (Bar arg) { fie(); }, void (Bar
 arg) { foe(); }, void (Bar arg) { fum(); } };

 Or even:

 typedef void (*callback)(Bar) callbacktype;
 callbacktype[] array = { callbacktype { fee(); }, callbacktype { fie(); },
 callbacktype { foe(); }, callbacktype { fum(); } };

 Sean

 "Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D9D1482.6000608 deming-os.org...
 Another obscure-yet-practical idea I ran across writing my program.  I
 have to code horde of little callback functions.  It would be nice to be
 able to declare them inline.  The current D code works something like

 this:
    struct Foo {
      void (*callback)(Bar);
    }

    Foo[] array;

    void Callback_0(Bar arg) {...};
    array[0].callback = &Callback_0;
    void Callback_1(Bar arg) {...};
    array[1].callback = &Callback_1;
    void Callback_2(Bar arg) {...};
    array[2].callback = &Callback_2;

 It would be a lot nicer to declare those functions inline.  For
 consistency with my anon-struct suggestion, I'll suggest we use the
 'anon' keyword here, too:

    array[0].callback = void anon(Bar arg) {...}
    array[1].callback = void anon(Bar arg) {...}
    array[2].callback = void anon(Bar arg) {...}

 Thoughts, anyone?

Mac Reiter <Mac_member pathlink.com> writes:

Oh, I am all about anonymous functions.  Once you start talking about _REALLY_
using 'foreach' style constructs, you _REALLY_ want to have anonymous functions.

Well, actually, given how D appears to be approaching 'foreach', you don't need
the anonymous functions, since the logic goes inside the loop scope.  But if you
are having to do STL-style generic iterative algorithms, anonymous functions are
extremely handy.  Since add-on libraries will eventually be made, it seems
reasonable to assume that this kind of thing will eventually appear, and it
would be nice to be ready for it...

Mac

In article <3D9D1482.6000608 deming-os.org>, Russell Lewis says...
Another obscure-yet-practical idea I ran across writing my program.  I 
have to code horde of little callback functions.  It would be nice to be 
able to declare them inline.  The current D code works something like this:

   struct Foo {
     void (*callback)(Bar);
   }

   Foo[] array;

   void Callback_0(Bar arg) {...};
   array[0].callback = &Callback_0;
   void Callback_1(Bar arg) {...};
   array[1].callback = &Callback_1;
   void Callback_2(Bar arg) {...};
   array[2].callback = &Callback_2;

It would be a lot nicer to declare those functions inline.  For 
consistency with my anon-struct suggestion, I'll suggest we use the 
'anon' keyword here, too:

   array[0].callback = void anon(Bar arg) {...}
   array[1].callback = void anon(Bar arg) {...}
   array[2].callback = void anon(Bar arg) {...}

Thoughts, anyone?

"Walter" <walter digitalmars.com> writes:

Great idea! I've been convinced for some time that anonymous functions are a
good idea and should be in D. When they go in is an open question, though.

"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D9D1482.6000608 deming-os.org...
 Another obscure-yet-practical idea I ran across writing my program.  I
 have to code horde of little callback functions.  It would be nice to be
 able to declare them inline.  The current D code works something like

this:
    struct Foo {
      void (*callback)(Bar);
    }

    Foo[] array;

    void Callback_0(Bar arg) {...};
    array[0].callback = &Callback_0;
    void Callback_1(Bar arg) {...};
    array[1].callback = &Callback_1;
    void Callback_2(Bar arg) {...};
    array[2].callback = &Callback_2;

 It would be a lot nicer to declare those functions inline.  For
 consistency with my anon-struct suggestion, I'll suggest we use the
 'anon' keyword here, too:

    array[0].callback = void anon(Bar arg) {...}
    array[1].callback = void anon(Bar arg) {...}
    array[2].callback = void anon(Bar arg) {...}

 Thoughts, anyone?

"Mike Wynn" <mike.wynn l8night.co.uk> writes:

will you been about to do ...

array[] = [ void anon(Bar arg) {...},
                    void anon(Bar arg) {...},
                    void anon(Bar arg) {...} ];

?


"Walter" <walter digitalmars.com> wrote in message
news:aotqan$v7d$1 digitaldaemon.com...
 Great idea! I've been convinced for some time that anonymous functions are

a
 good idea and should be in D. When they go in is an open question, though.

 "Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D9D1482.6000608 deming-os.org...
 Another obscure-yet-practical idea I ran across writing my program.  I
 have to code horde of little callback functions.  It would be nice to be
 able to declare them inline.  The current D code works something like

 this:
    struct Foo {
      void (*callback)(Bar);
    }

    Foo[] array;

    void Callback_0(Bar arg) {...};
    array[0].callback = &Callback_0;
    void Callback_1(Bar arg) {...};
    array[1].callback = &Callback_1;
    void Callback_2(Bar arg) {...};
    array[2].callback = &Callback_2;

 It would be a lot nicer to declare those functions inline.  For
 consistency with my anon-struct suggestion, I'll suggest we use the
 'anon' keyword here, too:

    array[0].callback = void anon(Bar arg) {...}
    array[1].callback = void anon(Bar arg) {...}
    array[2].callback = void anon(Bar arg) {...}

 Thoughts, anyone?

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

I don't see why you couldn't.  That certainly was the kind of things I was
hoping for.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Walter" <walter digitalmars.com> writes:

Yes, but the exact syntax is an open question. Haven't thought too much
about it yet.

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:aou3m6$17qj$1 digitaldaemon.com...
 will you been about to do ...

 array[] = [ void anon(Bar arg) {...},
                     void anon(Bar arg) {...},
                     void anon(Bar arg) {...} ];

 ?

"Sean L. Palmer" <seanpalmer directvinternet.com> writes:

Do either Walter or Burton think that D is sufficiently progressed to the
point that a D compiler could be written in D?

Sean

Burton Radons <loth users.sourceforge.net> writes:

Sean L. Palmer wrote:
 Do either Walter or Burton think that D is sufficiently progressed to the
 point that a D compiler could be written in D?

It is and would be quite a lot simpler than the current compiler.  The 
main problem with DMD here is that it doesn't handle recursive importing 
very nicely.

"Walter" <walter digitalmars.com> writes:

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:ap08iv$752$2 digitaldaemon.com...
 The
 main problem with DMD here is that it doesn't handle recursive importing
 very nicely.

Please expand on this, so I can address it.

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:aovoh2$2pko$1 digitaldaemon.com...
 Do either Walter or Burton think that D is sufficiently progressed to the
 point that a D compiler could be written in D?

Yes it has.