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?

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

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?
>

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"?

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?
> >
>
>

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"?

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?
>

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?
>

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?
> >
>
>

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))) ]