www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - __FUNCTION__

reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
Can we get this please?  It's so simple and would be terribly useful.
Feb 28 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Jarrett,

 Can we get this please?  It's so simple and would be terribly useful.
 

++vote;
Feb 28 2009
parent "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff30f38cb67a8ee93108e news.digitalmars.com...
 Hello Jarrett,

 Can we get this please?  It's so simple and would be terribly useful.

++vote;

repeat(1, BCS_comment());
Feb 28 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article
 Can we get this please?  It's so simple and would be terribly useful.

Can someone explain what __FUNCTION__ would do in a little more detail? I feel like the two posts of this thread so far are talking in secret __FUNCTION__-dealer code.
Feb 28 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:goc1k7$qml$1 digitalmars.com...
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s 
 article
 Can we get this please?  It's so simple and would be terribly useful.

Can someone explain what __FUNCTION__ would do in a little more detail? I feel like the two posts of this thread so far are talking in secret __FUNCTION__-dealer code.

void foofunc() { Stdout.formatln("{}", __FUNCTION__); } Output: foofunc Ie, basically the same as __FILE__ and __LINE__ and useful in the same ways. Also, I'd like to be able to do something like: Reflect.invoke(__FUNCTION__, params); Something funtionally equiveilent to that would aid maitenance of self-invoking functions (not only recusion, but also func overloads that are defined in terms of one "primary" overload). Also would be nice for similar reasons: __CLASS__ (or something similar that would also work for structs)
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:goc1k7$qml$1 digitalmars.com...
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s 
 article
 Can we get this please?  It's so simple and would be terribly useful.

feel like the two posts of this thread so far are talking in secret __FUNCTION__-dealer code.

void foofunc() { Stdout.formatln("{}", __FUNCTION__); } Output: foofunc Ie, basically the same as __FILE__ and __LINE__ and useful in the same ways.

I think instead of __FUNCTION__ we'll define a much more comprehensive static reflection facility.
 Also, I'd like to be able to do something like:
 
 Reflect.invoke(__FUNCTION__, params);

Yah... and Variant needs to have something similar as well. We know quite what std.reflect needs to look like, just we want to keep our fingers out of too many pies at once.
 Something funtionally equiveilent to that would aid maitenance of 
 self-invoking functions (not only recusion, but also func overloads that are 
 defined in terms of one "primary" overload).
 
 Also would be nice for similar reasons: __CLASS__ (or something similar that 
 would also work for structs) 

Yah. Andrei
Feb 28 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Andrei,

 Nick Sabalausky wrote:
 
 Stdout.formatln("{}", __FUNCTION__);

I think instead of __FUNCTION__ we'll define a much more comprehensive static reflection facility.

for the above case I think __FUNCTION__ is as good as it will get. Define it as a human readable identifier rather than reflection.
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:
 Hello Andrei,
 
 Nick Sabalausky wrote:

 Stdout.formatln("{}", __FUNCTION__);

I think instead of __FUNCTION__ we'll define a much more comprehensive static reflection facility.

for the above case I think __FUNCTION__ is as good as it will get. Define it as a human readable identifier rather than reflection.

You will have it as a human readable identifier too. The problem with __FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what happened to __STRUCT__, __MODULE__ et al?) can go forever. Andrei
Feb 28 2009
next sibling parent reply grauzone <none example.net> writes:
Andrei Alexandrescu wrote:
 BCS wrote:
 Hello Andrei,

 Nick Sabalausky wrote:

 Stdout.formatln("{}", __FUNCTION__);

I think instead of __FUNCTION__ we'll define a much more comprehensive static reflection facility.

for the above case I think __FUNCTION__ is as good as it will get. Define it as a human readable identifier rather than reflection.

You will have it as a human readable identifier too. The problem with __FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what happened to __STRUCT__, __MODULE__ et al?) can go forever.

For classes and structs, this is already possible: typeof(this).stringof Now we only need a way to get some kind of compile time object for functions and modules (like the type for classes/structs). Then you simply can use .stringof on them.
 
 Andrei

Feb 28 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 Andrei Alexandrescu wrote:
 BCS wrote:
 Hello Andrei,

 Nick Sabalausky wrote:

 Stdout.formatln("{}", __FUNCTION__);

I think instead of __FUNCTION__ we'll define a much more comprehensive static reflection facility.

for the above case I think __FUNCTION__ is as good as it will get. Define it as a human readable identifier rather than reflection.

You will have it as a human readable identifier too. The problem with __FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what happened to __STRUCT__, __MODULE__ et al?) can go forever.

For classes and structs, this is already possible: typeof(this).stringof

Not outside of a member function. This is crippling my Visitor implementation.
 Now we only need a way to get some kind of compile time object for 
 functions and modules (like the type for classes/structs). Then you 
 simply can use .stringof on them.

There's much more to reflection that we need to define. Andrei
Feb 28 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:
 grauzone wrote:
 For classes and structs, this is already possible: typeof(this).stringof

Not outside of a member function. This is crippling my Visitor implementation.

I use it in static constructors. If it doesn't work, well, that's news to me. I don't know about "typeof(this) property;", though. I never tried it.
 Now we only need a way to get some kind of compile time object for 
 functions and modules (like the type for classes/structs). Then you 
 simply can use .stringof on them.

There's much more to reflection that we need to define.

Runtime as well as compile time.
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Christopher Wright wrote:
 Andrei Alexandrescu wrote:
 grauzone wrote:
 For classes and structs, this is already possible: typeof(this).stringof

Not outside of a member function. This is crippling my Visitor implementation.

I use it in static constructors. If it doesn't work, well, that's news to me. I don't know about "typeof(this) property;", though. I never tried it.
 Now we only need a way to get some kind of compile time object for 
 functions and modules (like the type for classes/structs). Then you 
 simply can use .stringof on them.

There's much more to reflection that we need to define.

Runtime as well as compile time.

Compile-time. Runtime follows and only needs a little glue. Andrei
Feb 28 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:
 Christopher Wright wrote:
 Andrei Alexandrescu wrote:
 grauzone wrote:
 For classes and structs, this is already possible: 
 typeof(this).stringof

Not outside of a member function. This is crippling my Visitor implementation.

I use it in static constructors. If it doesn't work, well, that's news to me. I don't know about "typeof(this) property;", though. I never tried it.
 Now we only need a way to get some kind of compile time object for 
 functions and modules (like the type for classes/structs). Then you 
 simply can use .stringof on them.

There's much more to reflection that we need to define.

Runtime as well as compile time.

Compile-time. Runtime follows and only needs a little glue.

That glue requires user intervention. Would you add "mixin(Reflect);" to every class you wrote? But even that isn't sufficient -- you would have to implement some interface indicating that this class has reflection information, and pass objects around via that interface rather than using Object. There should be a way to suppress emitting complex reflection information -- a command-line flag and a pragma. But I think it's a bit much to ask users to mark every class they create in two different ways.
 Andrei

Mar 01 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"grauzone" <none example.net> wrote in message 
news:goc97a$15il$1 digitalmars.com...
 Andrei Alexandrescu wrote:
 BCS wrote:
 Hello Andrei,

 Nick Sabalausky wrote:

 Stdout.formatln("{}", __FUNCTION__);

I think instead of __FUNCTION__ we'll define a much more comprehensive static reflection facility.

for the above case I think __FUNCTION__ is as good as it will get. Define it as a human readable identifier rather than reflection.

You will have it as a human readable identifier too. The problem with __FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what happened to __STRUCT__, __MODULE__ et al?) can go forever.

For classes and structs, this is already possible: typeof(this).stringof Now we only need a way to get some kind of compile time object for functions and modules (like the type for classes/structs). Then you simply can use .stringof on them.

*smacks self in forehead*, You know, I've even used that in my own code already, and still didn't think of it when I made that post.
Feb 28 2009
prev sibling parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Andrei Alexandrescu wrote:
 BCS wrote:
 Hello Andrei,

 Nick Sabalausky wrote:

 Stdout.formatln("{}", __FUNCTION__);

I think instead of __FUNCTION__ we'll define a much more comprehensive static reflection facility.

for the above case I think __FUNCTION__ is as good as it will get. Define it as a human readable identifier rather than reflection.

You will have it as a human readable identifier too. The problem with __FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what happened to __STRUCT__, __MODULE__ et al?) can go forever.

These macros are the wrong idea. As you say the bare macros can go on forever. What is really needed in a reflection library is the ability to 'reflect' all D constructs, and you would get much more than just the name in such a library. So pushing for __FUNCTION__, __CLASS__ etc. etc. is just a quick-fix solution whereas a real reflection library gives so much more. I argued for this in the past on this NG but still no one seems to have picked up the idea that a full reflection library for D, supported fully by the compiler, would be a great thing. It would also allow RAD programming with D outside of the functionality one could use in 3rd party tools designed around full run-time reflection capabilities.
Feb 28 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Edward Diener wrote:
 I argued for this in the past on this NG but still no one seems to have 
 picked up the idea that a full reflection library for D, supported fully 
 by the compiler, would be a great thing. It would also allow RAD 
 programming with D outside of the functionality one could use in 3rd 
 party tools designed around full run-time reflection capabilities.

D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point. Andrei
Feb 28 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Sat, Feb 28, 2009 at 10:49 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Edward Diener wrote:
 I argued for this in the past on this NG but still no one seems to have
 picked up the idea that a full reflection library for D, supported fully by
 the compiler, would be a great thing. It would also allow RAD programming
 with D outside of the functionality one could use in 3rd party tools
 designed around full run-time reflection capabilities.

reflection.) It will be compile-time reflection because only run-time reflection only is missing the point.

Will it be implemented through __traits, or *yet another* compile-time introspection facility?

Whatever it'll be, I'm sure it will not shut off your whine noise generator :o). Andrei
Feb 28 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el  1 de marzo a las 11:07 me escribiste:
 On Sat, Feb 28, 2009 at 11:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Will it be implemented through __traits, or *yet another* compile-time
 introspection facility?

Whatever it'll be, I'm sure it will not shut off your whine noise generator :o).

:P I wasn't whining about it, I'd just rather not see a fifth method of compile-time introspection.

It will be nice not to use a keyword starting with "__" for a standard feature either because that prefix has a long history of being used for vendor-specific extensions (not to mention its awfulness =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Do not get mad with others Because they know more than you It is not their fault
Mar 02 2009
prev sibling parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Andrei Alexandrescu wrote:
 Edward Diener wrote:
 I argued for this in the past on this NG but still no one seems to 
 have picked up the idea that a full reflection library for D, 
 supported fully by the compiler, would be a great thing. It would also 
 allow RAD programming with D outside of the functionality one could 
 use in 3rd party tools designed around full run-time reflection 
 capabilities.

D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point.

The whole debate about "compile-time" and "run-time" reflection is irrelevant as long as one can invoke it without having to inject code into an already existing construct. It must work through run-time code which can ask such reflection questions as: enumerate for me all of the classes in a particular module etc., or enumerate for me all the functions in a class etc. . It must work by allowing code from outside of a construct to query that construct and get its accessible constructs. How that run-time code is written, whether using "compile-time" reflection using templates, or run-time classes accessible from a library whose reflection data is produced by the D compiler, is not important from the user's point of view as long as the user has the access he wants and can write relatively clean and clear code to get it. Of course from within any given construct one should also be able to write code in a clear manner which accesses the inner constructs. Access to constructs via reflection should follow the same protection features as any other code, so that public constructs are always accessible but private constructs are only accessible following their normal rules. So I do not know what you mean by "only run-time reflection only is missing the point" but certainly the ability to use reflection at run-time is vitally important from outside of a construct to any 3rd party tool which wants to introspect already existing constructs and create objects from those constructs based on the information run-time reflection can return.
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Edward Diener wrote:
 Andrei Alexandrescu wrote:
 Edward Diener wrote:
 I argued for this in the past on this NG but still no one seems to 
 have picked up the idea that a full reflection library for D, 
 supported fully by the compiler, would be a great thing. It would 
 also allow RAD programming with D outside of the functionality one 
 could use in 3rd party tools designed around full run-time reflection 
 capabilities.

D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point.

The whole debate about "compile-time" and "run-time" reflection is irrelevant as long as one can invoke it without having to inject code into an already existing construct. It must work through run-time code which can ask such reflection questions as: enumerate for me all of the classes in a particular module etc., or enumerate for me all the functions in a class etc. . It must work by allowing code from outside of a construct to query that construct and get its accessible constructs. How that run-time code is written, whether using "compile-time" reflection using templates, or run-time classes accessible from a library whose reflection data is produced by the D compiler, is not important from the user's point of view as long as the user has the access he wants and can write relatively clean and clear code to get it. Of course from within any given construct one should also be able to write code in a clear manner which accesses the inner constructs. Access to constructs via reflection should follow the same protection features as any other code, so that public constructs are always accessible but private constructs are only accessible following their normal rules. So I do not know what you mean by "only run-time reflection only is missing the point" but certainly the ability to use reflection at run-time is vitally important from outside of a construct to any 3rd party tool which wants to introspect already existing constructs and create objects from those constructs based on the information run-time reflection can return.

This is a long discussion, but in brief any runtime reflection engine needs some sort of compile-time metadata infrastructure. Some languages don't make that accessible within the language itself. Runtime reflection has been explored extensively, its possibilities and limitations are pretty well understood, I hardly smothered a yawn reading all you wrote. Compile-time reflection is much less understood and hides many more exciting possibilities. With the advances in compiler technology implemented by Walter, we have a chance to tackle reflection in a systematic manner. Andrei
Feb 28 2009
parent Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Andrei Alexandrescu wrote:
 Edward Diener wrote:
 Andrei Alexandrescu wrote:
 Edward Diener wrote:
 I argued for this in the past on this NG but still no one seems to 
 have picked up the idea that a full reflection library for D, 
 supported fully by the compiler, would be a great thing. It would 
 also allow RAD programming with D outside of the functionality one 
 could use in 3rd party tools designed around full run-time 
 reflection capabilities.

D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point.

The whole debate about "compile-time" and "run-time" reflection is irrelevant as long as one can invoke it without having to inject code into an already existing construct. It must work through run-time code which can ask such reflection questions as: enumerate for me all of the classes in a particular module etc., or enumerate for me all the functions in a class etc. . It must work by allowing code from outside of a construct to query that construct and get its accessible constructs. How that run-time code is written, whether using "compile-time" reflection using templates, or run-time classes accessible from a library whose reflection data is produced by the D compiler, is not important from the user's point of view as long as the user has the access he wants and can write relatively clean and clear code to get it. Of course from within any given construct one should also be able to write code in a clear manner which accesses the inner constructs. Access to constructs via reflection should follow the same protection features as any other code, so that public constructs are always accessible but private constructs are only accessible following their normal rules. So I do not know what you mean by "only run-time reflection only is missing the point" but certainly the ability to use reflection at run-time is vitally important from outside of a construct to any 3rd party tool which wants to introspect already existing constructs and create objects from those constructs based on the information run-time reflection can return.

This is a long discussion, but in brief any runtime reflection engine needs some sort of compile-time metadata infrastructure. Some languages don't make that accessible within the language itself. Runtime reflection has been explored extensively, its possibilities and limitations are pretty well understood, I hardly smothered a yawn reading all you wrote.

It was written because I have inevitably seen discussions about language reflection mechanisms end with talk about really neat new compile-time facilities which bring one no closer to real run-time reflection than before.
Compile-time reflection is much less understood 
 and hides many more exciting possibilities. With the advances in 
 compiler technology implemented by Walter, we have a chance to tackle 
 reflection in a systematic manner.

Good ! I look forward to seeing it and using it in D.
Mar 01 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Edward Diener wrote:
 I argued for this in the past on this NG but still no one seems to have 
 picked up the idea that a full reflection library for D, supported fully 
 by the compiler, would be a great thing. It would also allow RAD 
 programming with D outside of the functionality one could use in 3rd 
 party tools designed around full run-time reflection capabilities.

I believe it is a great idea, it's just that there are so many that I'm swamped.
Feb 28 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 4:10 PM, grauzone <none example.net> wrote:
 For classes and structs, this is already possible: typeof(this).stringof

 Now we only need a way to get some kind of compile time object for functions
 and modules (like the type for classes/structs). Then you simply can use
 .stringof on them.

Oh, that'd be nice. It'd be even nicer if .stringof had any more documentation than "returns a string representation of something." Like what format it's supposed to be in, what you're supposed to get when you get the string of something like: struct S { int x; } pragma(msg, S.x.stringof); that kind of stuff. As it is I have *no* idea if any of my uses of stringof are legal, and it worries me even more that other compilers will freely implement it any way they choose, breaking my code on anything but DMDFE.
Feb 28 2009
prev sibling next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
Denis Koroskin wrote:

 On Sat, 28 Feb 2009 23:39:41 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Nick Sabalausky wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message
 news:goc1k7$qml$1 digitalmars.com...
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s
 article
 Can we get this please?  It's so simple and would be terribly useful.

detail? I feel like the two posts of this thread so far are talking in secret __FUNCTION__-dealer code.

{ Stdout.formatln("{}", __FUNCTION__); } Output: foofunc Ie, basically the same as __FILE__ and __LINE__ and useful in the same ways.

I think instead of __FUNCTION__ we'll define a much more comprehensive static reflection facility.
 Also, I'd like to be able to do something like:
  Reflect.invoke(__FUNCTION__, params);

Yah... and Variant needs to have something similar as well. We know quite what std.reflect needs to look like, just we want to keep our fingers out of too many pies at once.
 Something funtionally equiveilent to that would aid maitenance of
 self-invoking functions (not only recusion, but also func overloads
 that are defined in terms of one "primary" overload).
  Also would be nice for similar reasons: __CLASS__ (or something
 similar that would also work for structs)

Yah. Andrei

Yes. When writing a recursive function, it is often desired to have a way to call the function recursively via some shortcut, something like 'fthis' (this function). It would be great to have something like this in D. That way _FUNCTION__ could be replaced by 'fthis.stringof' or something similar. It also gives small other advantages (easier code refactoring etc). Here is an example: int factorial(int c) { //writefln(fthis.stringof); //writefln(typeof(fthis).stringof); if (c < 2) return 1; return fthis(c - 1) * c; }

"fthis" does not sounds like a nice keyword. How about "self"?
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Johan Granberg wrote:
 Denis Koroskin wrote:
 
 On Sat, 28 Feb 2009 23:39:41 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message
 news:goc1k7$qml$1 digitalmars.com...
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s
 article
 Can we get this please?  It's so simple and would be terribly useful.

detail? I feel like the two posts of this thread so far are talking in secret __FUNCTION__-dealer code.

{ Stdout.formatln("{}", __FUNCTION__); } Output: foofunc Ie, basically the same as __FILE__ and __LINE__ and useful in the same ways.

static reflection facility.
 Also, I'd like to be able to do something like:
  Reflect.invoke(__FUNCTION__, params);

quite what std.reflect needs to look like, just we want to keep our fingers out of too many pies at once.
 Something funtionally equiveilent to that would aid maitenance of
 self-invoking functions (not only recusion, but also func overloads
 that are defined in terms of one "primary" overload).
  Also would be nice for similar reasons: __CLASS__ (or something
 similar that would also work for structs)

Andrei

to call the function recursively via some shortcut, something like 'fthis' (this function). It would be great to have something like this in D. That way _FUNCTION__ could be replaced by 'fthis.stringof' or something similar. It also gives small other advantages (easier code refactoring etc). Here is an example: int factorial(int c) { //writefln(fthis.stringof); //writefln(typeof(fthis).stringof); if (c < 2) return 1; return fthis(c - 1) * c; }

"fthis" does not sounds like a nice keyword. How about "self"?

We better use "..". int factorial(int c) { //writefln(fthis.stringof); //writefln(typeof(fthis).stringof); if (c < 2) return 1; return ..(c - 1) * c; } Andrei
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Sat, Feb 28, 2009 at 4:50 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 We better use "..".

  int factorial(int c)
  {
     //writefln(fthis.stringof);
     //writefln(typeof(fthis).stringof);

     if (c < 2) return 1;
     return ..(c - 1) * c;
  }

I hope this is a sarcastic reply :P

My second. I was afraid the first one wasn't transparent enough. Andrei
Feb 28 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu escribió:
 Jarrett Billingsley wrote:
 On Sat, Feb 28, 2009 at 4:50 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 We better use "..".

  int factorial(int c)
  {
     //writefln(fthis.stringof);
     //writefln(typeof(fthis).stringof);

     if (c < 2) return 1;
     return ..(c - 1) * c;
  }

I hope this is a sarcastic reply :P

My second. I was afraid the first one wasn't transparent enough.

The contextual keyword iota, right?
 
 Andrei

Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu escribió:
 Jarrett Billingsley wrote:
 On Sat, Feb 28, 2009 at 4:50 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 We better use "..".

  int factorial(int c)
  {
     //writefln(fthis.stringof);
     //writefln(typeof(fthis).stringof);

     if (c < 2) return 1;
     return ..(c - 1) * c;
  }

I hope this is a sarcastic reply :P

My second. I was afraid the first one wasn't transparent enough.

The contextual keyword iota, right?

That's the one! I think it even got a serious answer :o). Andrei
Feb 28 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 Andrei Alexandrescu escribió:
 Jarrett Billingsley wrote:
 On Sat, Feb 28, 2009 at 4:50 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 We better use "..".

  int factorial(int c)
  {
     //writefln(fthis.stringof);
     //writefln(typeof(fthis).stringof);

     if (c < 2) return 1;
     return ..(c - 1) * c;
  }

I hope this is a sarcastic reply :P

My second. I was afraid the first one wasn't transparent enough.

The contextual keyword iota, right?

That's the one! I think it even got a serious answer :o).

Sarcasm starts working against the author if less than 25% of the audience recognize it. --anon
Mar 01 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 10:49 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Edward Diener wrote:
 I argued for this in the past on this NG but still no one seems to have
 picked up the idea that a full reflection library for D, supported fully by
 the compiler, would be a great thing. It would also allow RAD programming
 with D outside of the functionality one could use in 3rd party tools
 designed around full run-time reflection capabilities.

D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point.

Will it be implemented through __traits, or *yet another* compile-time introspection facility?
Feb 28 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 11:46 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Will it be implemented through __traits, or *yet another* compile-time
 introspection facility?

Whatever it'll be, I'm sure it will not shut off your whine noise generator :o).

:P I wasn't whining about it, I'd just rather not see a fifth method of compile-time introspection.
Mar 01 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 2:15 PM, Nick Sabalausky <a a.a> wrote:
 void foofunc()
 {
 =A0 =A0Stdout.formatln("{}", __FUNCTION__);
 }

 Output:
 foofunc

It would probably be the fully-qualified name, especially when you consider using it for reflection.
Feb 28 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 28 Feb 2009 23:39:41 +0300, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message  
 news:goc1k7$qml$1 digitalmars.com...
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s  
 article
 Can we get this please?  It's so simple and would be terribly useful.

detail? I feel like the two posts of this thread so far are talking in secret __FUNCTION__-dealer code.

{ Stdout.formatln("{}", __FUNCTION__); } Output: foofunc Ie, basically the same as __FILE__ and __LINE__ and useful in the same ways.

I think instead of __FUNCTION__ we'll define a much more comprehensive static reflection facility.
 Also, I'd like to be able to do something like:
  Reflect.invoke(__FUNCTION__, params);

Yah... and Variant needs to have something similar as well. We know quite what std.reflect needs to look like, just we want to keep our fingers out of too many pies at once.
 Something funtionally equiveilent to that would aid maitenance of  
 self-invoking functions (not only recusion, but also func overloads  
 that are defined in terms of one "primary" overload).
  Also would be nice for similar reasons: __CLASS__ (or something  
 similar that would also work for structs)

Yah. Andrei

Yes. When writing a recursive function, it is often desired to have a way to call the function recursively via some shortcut, something like 'fthis' (this function). It would be great to have something like this in D. That way _FUNCTION__ could be replaced by 'fthis.stringof' or something similar. It also gives small other advantages (easier code refactoring etc). Here is an example: int factorial(int c) { //writefln(fthis.stringof); //writefln(typeof(fthis).stringof); if (c < 2) return 1; return fthis(c - 1) * c; }
Feb 28 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 4:50 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 We better use "..".

 =A0int factorial(int c)
 =A0{
 =A0 =A0 //writefln(fthis.stringof);
 =A0 =A0 //writefln(typeof(fthis).stringof);

 =A0 =A0 if (c < 2) return 1;
 =A0 =A0 return ..(c - 1) * c;
 =A0}

I hope this is a sarcastic reply :P
Feb 28 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 28 Feb 2009 12:30:35 -0500, Jarrett Billingsley wrote:

 Can we get this please?  It's so simple and would be terribly useful.

void foo() { writefln(__FUNCTION__); } void foo(int x) { writefln(__FUNCTION__); } ------------------- module bar; void foo() { writefln(__FUNCTION__); } ---------------- class One { void foo() { writefln(__FUNCTION__); } } struct Two { void foo() { writefln(__FUNCTION__); } } -------------- Any problems so far? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 28 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 28 Feb 2009 17:27:27 -0500, Jarrett Billingsley wrote:

 On Sat, Feb 28, 2009 at 5:24 PM, Derek Parnell <derek psych.ward> wrote:
 void foo()
 {
    writefln(__FUNCTION__);
 }

 void foo(int x)
 {
    writefln(__FUNCTION__);
 }


 I mentioned in a follow-up post that it would probably have to give a
 fully-qualified name in the presence of multiple modules and nesting
 and such. 

Ah yes, I read that now ... {note to self: Should read all posts before replying :-)}
 As for multiple overloads - so what?  All I want is the
 name of the function.

But why? There could be conceivable circumstances in which one needed to know *which* 'foo' issued the message, one might need finer or more details to know that. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 28 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 28 Feb 2009 17:42:55 -0500, Jarrett Billingsley wrote:

 Then, as Andrei suggested, we need a more flexible and fine-grained
 reflection mechanism.  :)

Agreed, but are you also suggesting that a simple __FUNCTION__ should also exist? By the way, my fear for D is that it is turning into an ASCII version of APL. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Sat, 28 Feb 2009 17:42:55 -0500, Jarrett Billingsley wrote:
 
 Then, as Andrei suggested, we need a more flexible and fine-grained
 reflection mechanism.  :)

Agreed, but are you also suggesting that a simple __FUNCTION__ should also exist? By the way, my fear for D is that it is turning into an ASCII version of APL.

I don't know much about APL, what was wrong with it? Andrei
Feb 28 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 I don't know much about APL, what was wrong with it?

It needed a special keyboard.
Feb 28 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 I don't know much about APL, what was wrong with it?

It needed a special keyboard.

There is an input method for APL that supports standard keyboards, I believe.
Feb 28 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Christopher Wright wrote:
 Walter Bright wrote:
 Andrei Alexandrescu wrote:
 I don't know much about APL, what was wrong with it?

It needed a special keyboard.

There is an input method for APL that supports standard keyboards, I believe.

Yeah, many kludge-o-matic workarounds have appeared over the years, none of which are very satisfactory.
Feb 28 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 On Sat, 28 Feb 2009 17:42:55 -0500, Jarrett Billingsley wrote:

 Then, as Andrei suggested, we need a more flexible and fine-grained
 reflection mechanism.  :)

Agreed, but are you also suggesting that a simple __FUNCTION__ should also exist? By the way, my fear for D is that it is turning into an ASCII version of APL.

I don't know much about APL, what was wrong with it?

Plenty. It was a write-only language, on a par with brainf**ck. I've known guru-level apl programmers who regularly couldn't read their own code the next week. It's probably the most concise way of writing heavy and ultra efficient data manipulation code. It's a bit like spending a week writing an 80-character hairy regexp, and later trying to figure out how the heck it actually works. ---- But I think some of us should stick with D1.
Mar 01 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 5:24 PM, Derek Parnell <derek psych.ward> wrote:
 On Sat, 28 Feb 2009 12:30:35 -0500, Jarrett Billingsley wrote:

 Can we get this please? =A0It's so simple and would be terribly useful.

void foo() { =A0 =A0writefln(__FUNCTION__); } void foo(int x) { =A0 =A0writefln(__FUNCTION__); } ------------------- module bar; void foo() { =A0 =A0writefln(__FUNCTION__); } ---------------- class One { =A0void foo() =A0{ =A0 =A0 writefln(__FUNCTION__); =A0} } struct Two { =A0void foo() =A0{ =A0 =A0 writefln(__FUNCTION__); =A0} } -------------- Any problems so far?

I mentioned in a follow-up post that it would probably have to give a fully-qualified name in the presence of multiple modules and nesting and such. As for multiple overloads - so what? All I want is the name of the function.
Feb 28 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 5:35 PM, Derek Parnell <derek psych.ward> wrote:
 As for multiple overloads - so what? =A0All I want is the
 name of the function.

But why? There could be conceivable circumstances in which one needed to know *which* 'foo' issued the message, one might need finer or more detai=

 to know that.

Then, as Andrei suggested, we need a more flexible and fine-grained reflection mechanism. :)
Feb 28 2009