On Wednesday, July 18, 2012 00:03:25 bearophile wrote:
> angel:
> > I propose to introduce a reference to the current function, much like 'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
> 
> Or __func or something. I'm asking for it for years.

You could always use __FUNCTION__ in a string mixin, but that _is_ rather ugly.

- Jonathan M Davis

> You could always use __FUNCTION__ in a string mixin, but that _is_ rather ugly.

Like this ?
	auto fac = delegate(int n) {
		if (n <= 1)
			return 1;
		return n * mixin(__FUNCTION__)(n - 1);
	};

Well, there are a few problems with this:
- it _is_ ugly
- some 'automatic' name should be generated internally (possibly it is in any case)
- it doesn't currently work

Possibly more streamlined approach would be:
thisFunc (or 'self', or whatever)
thisFunc.stringof istead of __FUNCTION__

On 07/18/12 01:05, Kevin Cox wrote:
> 
> On Jul 17, 2012 6:50 PM, "Era Scarecrow" <rtcvb32@yahoo.com <mailto:rtcvb32@yahoo.com>> wrote:
>>
>> On Tuesday, 17 July 2012 at 22:13:13 UTC, Eyyub wrote:
>>>
>>> On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
>>>>
>>>> I propose to introduce a reference to the current function, much like 'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
>>>> What might this be good for ?
>>>> For implementing recursion in a lambda function. Writing in functional style, one creates many functions, and looking for reasonable names for these functions becomes unnecessarily painful.
>>>
>>>
>>> Good idea !
>>> "self" is a cute keyword, or "lambda" but this could break existing code.
>>
>>
>> Mmm.. Why not an inner function to represent the recursive function? True a 'self' reference may resolve the issue,
> 
> What about how JavaScript does it.  Anonymous functions can still have a "name" that can be used from inside of a function to refer to itself.
> 
> And the most useless example ever.
> 
> var f = function func ( i ) {
>     return func(7);
> };
> 
> I think that this is nice because there is no name space pollution, no new keywords needed and it is pretty.
> 
Sadly, this collides with the return-type syntax already in place.

auto f = function int(int i) { return 0; };

On Jul 18, 2012 6:20 AM, "FeepingCreature" <default_357-line@yahoo.de> wrote:
>
> On 07/18/12 01:05, Kevin Cox wrote:
> >

> > What about how JavaScript does it.  Anonymous functions can still have
a "name" that can be used from inside of a function to refer to itself.
> Sadly, this collides with the return-type syntax already in place.
>
> auto f = function int(int i) { return 0; };

True, but the concept could still be used, we just need some syntax.

> True, but the concept could still be used, we just need some syntax.

IMHO introducing a new keyword is the clearest solution.
As for the danger of breaking existing code, let's face it, there is no whole world legacy written in D with extensive use of 'thisFunc' keyword.

On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
> I propose to introduce a reference to the current function, much like 'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
> What might this be good for ?
> For implementing recursion in a lambda function.
> Writing in functional style, one creates many functions, and looking for reasonable names for these functions becomes unnecessarily painful.

Recursive lambdas? o.O

Instead of changing the language, I'd say your situation merits using the Y combinator... maybe define Y(f) to be (g => g(g))(g => f(x => g(g)(x)))
then if you need to define factorial, just say...
fact = Y(fact => n => n > 0 ? n * fact(n - 1) : 1);

On 07/19/2012 04:54 AM, Mehrdad wrote:
> On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
>> I propose to introduce a reference to the current function, much like
>> 'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
>> What might this be good for ?
>> For implementing recursion in a lambda function.
>> Writing in functional style, one creates many functions, and looking
>> for reasonable names for these functions becomes unnecessarily painful.
>
> Recursive lambdas? o.O
>
> Instead of changing the language, I'd say your situation merits using
> the Y combinator... maybe define Y(f) to be (g => g(g))(g => f(x =>
> g(g)(x)))
> then if you need to define factorial, just say...
> fact = Y(fact => n => n > 0 ? n * fact(n - 1) : 1);
>
>


- D does/can not have full type inference, because the type system with
  templates is Turing complete.

- There is no way this is going to type check even with explicit type
  annotations, because there are no recursive function types.

- Allocation of closures for control flow is not going to work
  efficiently with the current GC.

- D actually has named functions, there is no need to use the anonymous
  lambda based y combinator to make up for the lack of them.

On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
> I propose to introduce a reference to the current function, much like 'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
> What might this be good for ?
> For implementing recursion in a lambda function.
> Writing in functional style, one creates many functions, and looking for reasonable names for these functions becomes unnecessarily painful.

May I suggest the "recur" or "recursive" keyword?

auto factorials = map!(n => n ? n * recur(n-1) : 1)([1, 2, 3]).array;
assert(factorials == [1, 2, 6]);

NMS

I was just about to make this proposal myself before searching to see if it had already been discussed, so here I am.

The requirement for self-referencing is a lot more profound than providing only a means to self-reference a calling function (runtime or during compile time).

I recently decided to drop C++ and commit to using D for a production system (yeah I'm taking a risk), and almost immediately the first problem I encounter is this insanely frustrating inability:

For logging errors in my code, I want to log the calling function name along with other applicable information. I can do a lot with D, but I cannot get access to the calling function name in a reasonable way (all solutions I have found so far are IMO unreasonable).

I can easily log class names from a member function, eg typeof(this).stringof

So why can't I do a similar thing with member functions? or any other type that has internal member code? or more profoundly, any type in general eg entity.this?

(I know 'this' is a special key word, I re-use it to illustrate the point)

I recall how it was nice to hear that D did away with the need to prefix class names onto cstors and dstors (that was required for more than one reason), so here is the opportunity to do the same thing with functions, such that recursive calling does not require explicityly re-naming the same function over again.

I also realize that there's a need to introduce better compile time reflection and runtime reflection, so here is an opportunity to unify a few things that directly apply to both of these efforts.

Self-referencing should be generalized and applicable to all entities, not just classes and structs. It could make templates easier to write, it directly applies to improved compile and runtime reflection, and it elegantly solves real world proplems, such as my simple error logger requirement.

--rt

Wild stab in the dark, but would something like this work:

void myfunction() {
	int dummy;
	auto self = __traits(parent, dummy);
}

though it would be better if something like __traits(enclosing) were supported.

On 18/09/2012 20:22, Rob T wrote:
> I was just about to make this proposal myself before searching to see if
> it had already been discussed, so here I am.
>
> The requirement for self-referencing is a lot more profound than
> providing only a means to self-reference a calling function (runtime or
> during compile time).
>
> I recently decided to drop C++ and commit to using D for a production
> system (yeah I'm taking a risk), and almost immediately the first
> problem I encounter is this insanely frustrating inability:
>
> For logging errors in my code, I want to log the calling function name
> along with other applicable information. I can do a lot with D, but I
> cannot get access to the calling function name in a reasonable way (all
> solutions I have found so far are IMO unreasonable).
>
> I can easily log class names from a member function, eg
> typeof(this).stringof
>
> So why can't I do a similar thing with member functions? or any other
> type that has internal member code? or more profoundly, any type in
> general eg entity.this?
>
> (I know 'this' is a special key word, I re-use it to illustrate the point)
>
> I recall how it was nice to hear that D did away with the need to prefix
> class names onto cstors and dstors (that was required for more than one
> reason), so here is the opportunity to do the same thing with functions,
> such that recursive calling does not require explicityly re-naming the
> same function over again.
>
> I also realize that there's a need to introduce better compile time
> reflection and runtime reflection, so here is an opportunity to unify a
> few things that directly apply to both of these efforts.
>
> Self-referencing should be generalized and applicable to all entities,
> not just classes and structs. It could make templates easier to write,
> it directly applies to improved compile and runtime reflection, and it
> elegantly solves real world proplems, such as my simple error logger
> requirement.
>
> --rt
>