This should be possible in D:

inline int foo(0)
{
return 0;
}

int foo(int i)
{
return 10/i;
}

int main()
{
int i=0;
int j;
j=foo(i++); // if (i==0) j=0; else j=foo(i)
j+=foo(i++); // if (i==0) j+=0; else j+=foo(i)
return 0;
}

In the current version:

template foo(int i)
{
	int foo()
	{
		return 10 / i;
	}
}
template foo(int i: 0)
{
	int foo()
	{
		return 0;
	}
}

In the next version:

template foo(int i)
{
	int foo()
	{
		static if (i == 0)
			return 0;
		else
			return 10 / i;
	}
}

Both are used in the following way:

int main()
{
	int i = 0;
	int j;

	j = foo!(i++);
	j += foo!(i++);

	return 0;
}

So, yes, it should be - and is - possible in D ;).

-[Unknown]


> This should be possible in D:
> 
> inline int foo(0)
> {
> return 0;
> }
> 
> int foo(int i)
> {
> return 10/i;
> }
> 
> int main()
> {
> int i=0;
> int j;
> j=foo(i++); // if (i==0) j=0; else j=foo(i)
> j+=foo(i++); // if (i==0) j+=0; else j+=foo(i)
> return 0;
> }
> 
> 
> 

In article <d677hq$2nh7$1@digitaldaemon.com>, Antti says...
>
>This should be possible in D:
>
>inline int foo(0)
>{
>return 0;
>}
>
>int foo(int i)
>{
>return 10/i;
>}
>
>int main()
>{
>int i=0;
>int j;
>j=foo(i++); // if (i==0) j=0; else j=foo(i)
>j+=foo(i++); // if (i==0) j+=0; else j+=foo(i)
>return 0;
>}
>
>
>

Ah, function overloading based on parameter *value*. I like it! Though the example is tiny, the concept seems highly powerful.

Would that also mean that I could do something like:

void handleToken("//") { ... }
void handleToken("/*") { ... }
void handleToken(char[] t) { ... }

and have a corresponding switch statement is generated on function invocation?

Though I would assume this would add a quite bit of compiler complexity, it would close the void left by the lack of a preprocessor further, not to mention saving me a lot of typing :)

In article <d67aie$2p6q$1@digitaldaemon.com>, Unknown W. Brackets says...
>
>In the current version:
>
>template foo(int i)
>{
>	int foo()
>	{
>		return 10 / i;
>	}
>}
>template foo(int i: 0)
>{
>	int foo()
>	{
>		return 0;
>	}
>}
>
>In the next version:
>
>template foo(int i)
>{
>	int foo()
>	{
>		static if (i == 0)
>			return 0;
>		else
>			return 10 / i;
>	}
>}
>
>Both are used in the following way:
>
>int main()
>{
>	int i = 0;
>	int j;
>
>	j = foo!(i++);
>	j += foo!(i++);
>
>	return 0;
>}
>
>So, yes, it should be - and is - possible in D ;).
>
>-[Unknown]
>
>

Are you sure that's true? Sorry, I'm new to D so maybe I'm missing something. But in the case above, the value of i is not known until run time, whereas in Walter's example of static if, the parameter is a constant at compile time.

Jim

Nod wrote:
> In article <d677hq$2nh7$1@digitaldaemon.com>, Antti says...
> 
>>This should be possible in D:
>>
>>inline int foo(0)
>>{
>>return 0;
>>}
>>
>>int foo(int i)
>>{
>>return 10/i;
>>}
>>
>>int main()
>>{
>>int i=0;
>>int j;
>>j=foo(i++); // if (i==0) j=0; else j=foo(i)
>>j+=foo(i++); // if (i==0) j+=0; else j+=foo(i)
>>return 0;
>>}
>>
>>
>>
> 
> 
> Ah, function overloading based on parameter *value*. I like it! Though the
> example is tiny, the concept seems highly powerful.
> 
> Would that also mean that I could do something like:
> 
> void handleToken("//") { ... }
> void handleToken("/*") { ... }
> void handleToken(char[] t) { ... }
> 
> and have a corresponding switch statement is generated on function invocation?
> 
> Though I would assume this would add a quite bit of compiler complexity, it
> would close the void left by the lack of a preprocessor further, not to mention
> saving me a lot of typing :)
> 
> 

This is called 'pattern matching' in the functional programming world, and its used pretty extensively.

-DavidM

Antti wrote:
> This should be possible in D:
> 
> inline int foo(0)
> {
> return 0;
> }
> 
> int foo(int i)
> {
> return 10/i;
> }
> 
> int main()
> {
> int i=0;
> int j;
> j=foo(i++); // if (i==0) j=0; else j=foo(i)
> j+=foo(i++); // if (i==0) j+=0; else j+=foo(i)
> return 0;
> }

What's wrong with

int foo(int a)
{
    return a ? 10/a : 0;
}

I mean, I don't get the benefit, either performance-wise, or ease-of-use-wise..


xs0

In article <d681rq$6ll$1@digitaldaemon.com>, David Medlock says...
>
>Nod wrote:
>> In article <d677hq$2nh7$1@digitaldaemon.com>, Antti says...
>> 
>>>This should be possible in D:
>>>
>>>inline int foo(0)
>>>{
>>>return 0;
>>>}
>>>
>>>int foo(int i)
>>>{
>>>return 10/i;
>>>}
>>>
>>>int main()
>>>{
>>>int i=0;
>>>int j;
>>>j=foo(i++); // if (i==0) j=0; else j=foo(i)
>>>j+=foo(i++); // if (i==0) j+=0; else j+=foo(i)
>>>return 0;
>>>}
>>>
>>>
>>>
>> 
>> 
>> Ah, function overloading based on parameter *value*. I like it! Though the example is tiny, the concept seems highly powerful.
>> 
>> Would that also mean that I could do something like:
>> 
>> void handleToken("//") { ... }
>> void handleToken("/*") { ... }
>> void handleToken(char[] t) { ... }
>> 
>> and have a corresponding switch statement is generated on function invocation?
>> 
>> Though I would assume this would add a quite bit of compiler complexity, it would close the void left by the lack of a preprocessor further, not to mention saving me a lot of typing :)
>> 
>> 
>
>This is called 'pattern matching' in the functional programming world, and its used pretty extensively.
>
>-DavidM


Heh, I actually had a feeling that it had something to do with functional programming. I've been thinking of checking haskell out one of these days.

Well, functional or not, it looks tremendously useful. One could do away with *a lot* of explicit program flow control, and simply let the compiler "piece things together".

Hmm, maybe it could also simplify some of the common cases in contract programming... Like, instead of having

:void foo(int month)
:in {
:  assert(month > 0 && month <= 12);
:}
:body { ... }

one would simply have

:void foo(int:0 < month <= 12) { ... }

and both would react similarly on invalid values of course.

Thoughts?

The compiler can do basic inlining.

-[Unknown]


> In article <d67aie$2p6q$1@digitaldaemon.com>, Unknown W. Brackets says...
> 
>>In the current version:
>>
>>template foo(int i)
>>{
>>	int foo()
>>	{
>>		return 10 / i;
>>	}
>>}
>>template foo(int i: 0)
>>{
>>	int foo()
>>	{
>>		return 0;
>>	}
>>}
>>
>>In the next version:
>>
>>template foo(int i)
>>{
>>	int foo()
>>	{
>>		static if (i == 0)
>>			return 0;
>>		else
>>			return 10 / i;
>>	}
>>}
>>
>>Both are used in the following way:
>>
>>int main()
>>{
>>	int i = 0;
>>	int j;
>>
>>	j = foo!(i++);
>>	j += foo!(i++);
>>
>>	return 0;
>>}
>>
>>So, yes, it should be - and is - possible in D ;).
>>
>>-[Unknown]
>>
>>
> 
> 
> Are you sure that's true? Sorry, I'm new to D so maybe I'm missing something.
> But in the case above, the value of i is not known until run time, whereas in
> Walter's example of static if, the parameter is a constant at compile time. 
> 
> Jim
> 
> 

xs0 wrote:
> Antti wrote:
> 
>> This should be possible in D:
>>
>> inline int foo(0)
>> {
>> return 0;
>> }
>>
>> int foo(int i)
>> {
>> return 10/i;
>> }
>>
>> int main()
>> {
>> int i=0;
>> int j;
>> j=foo(i++); // if (i==0) j=0; else j=foo(i)
>> j+=foo(i++); // if (i==0) j+=0; else j+=foo(i)
>> return 0;
>> }
> 
> 
> What's wrong with
> 
> int foo(int a)
> {
>     return a ? 10/a : 0;
> }
> 
> I mean, I don't get the benefit, either performance-wise, or ease-of-use-wise..
> 
> 
> xs0


There are a few benefits which come with pattern matching.

1. Readability.  Your example is short but it also requires the person reading the code to understand ALL the possibilities to add/remove/change one.   If each possibility has its own function, it becomes more modular.


2.  Optimization.  List comprehensions have some opportunities for caching results which arent possible with functions.

list  getOdd( list mylist )
{
  list result = new list();
  foreach( int a; mylist ) if ( !( a & 1 ) ) result.add( a );
  return result;
}

theres no way to know(for the compiler) ahead of time that this function is cacheable( ie that if the contents of the list do not change, the result of the function won't either )

Now try this:

list a = mylist[ x -> ( x & 1 == 0 ) ];

Cleaner and no state dependent results.  This need only be computed once per list.

Haskell goes a step further and will not execute code until it needs the result!

I am probably making myself as clear as mud...
-DavidM

In article <d6a46u$1mth$1@digitaldaemon.com>, David Medlock says...
>
>xs0 wrote:
>> Antti wrote:
>> 
>>> This should be possible in D:
>>>
>>> inline int foo(0)
>>> {
>>> return 0;
>>> }
>>>
>>> int foo(int i)
>>> {
>>> return 10/i;
>>> }
>>>
>>> int main()
>>> {
>>> int i=0;
>>> int j;
>>> j=foo(i++); // if (i==0) j=0; else j=foo(i)
>>> j+=foo(i++); // if (i==0) j+=0; else j+=foo(i)
>>> return 0;
>>> }
>> 
>> 
>> What's wrong with
>> 
>> int foo(int a)
>> {
>>     return a ? 10/a : 0;
>> }
>> 
>> I mean, I don't get the benefit, either performance-wise, or ease-of-use-wise..
>> 
>> 
>> xs0
>
>
>There are a few benefits which come with pattern matching.
>
>1. Readability.  Your example is short but it also requires the person reading the code to understand ALL the possibilities to add/remove/change one.   If each possibility has its own function, it becomes more modular.
>

True, true. On the same note, it would be possible to separate special cases from the main algorithm, thus keeping the main algorithm "clean".

>
>2.  Optimization.  List comprehensions have some opportunities for caching results which arent possible with functions.
>
>list  getOdd( list mylist )
>{
>   list result = new list();
>   foreach( int a; mylist ) if ( !( a & 1 ) ) result.add( a );
>   return result;
>}
>
>theres no way to know(for the compiler) ahead of time that this function is cacheable( ie that if the contents of the list do not change, the result of the function won't either )
>
>Now try this:
>
>list a = mylist[ x -> ( x & 1 == 0 ) ];
>
>Cleaner and no state dependent results.  This need only be computed once per list.
>

Hmm, I fail to see how list comprehension relates to pattern matching... Arent they quite different creatures?

And other than improving readability and reducing typing, wouldnt pattern matching be equal, performance-wise, to a regular if-else/switch construct?

>Haskell goes a step further and will not execute code until it needs the result!
>

Wee... Precomputation out the window. That doesnt sound good for interactive stuff.

>I am probably making myself as clear as mud...
>-DavidM

If everything was as clear as water, who would bother getting wet to see what is
underneath?  ;)
-Nod-