type switch

2015-05-04 Thread Dennis Ritchie via Digitalmars-d

Good day to all!

I've been thinking. In D you can write a similar design to the 
generic functions or somewhere, use static if:


// -
static if (is(T == short) || is(T == int) || is(T == long)) {
// do anything
} else static if (is(T == real)) {
// ...
} else static if (is(T == char)) {
// ...
} else static if (is(T == string)) {
// ...
} else static if (is(T == int[])) {
// ...
} else {
// ...
}

Why not put in Phobos shorter design type switch:

// -
type switch (T) {
case short, int, long:
// do anything
case real:
// ...
case char:
// ...
case string:
// ...
case int[]:
// ...
default:
// ...
}

This design has been implemented, for example, in Common Lisp 
(typecase):

http://www.lispworks.com/documentation/lw51/CLHS/Body/m_tpcase.htm

What do you think about this?


type switch

2009-09-01 Thread Paul D. Anderson
I came across Lava, an experimental programming language ("What's hotter than 
Java?") http://lavape.sourceforge.net/LavaHomePage.htm Lava has some curious 
features (they claim to have no syntax, but the syntax is just hidden by the 
"programming environment").

One of the evils of other programming languages, according to the website, is 
the infamous type cast: "Type casts are not only ugly, nasty, and annoying but 
much worse: their justification can only be assessed on the basis of a more 
comprehensive understanding of the dynamic program behavior in general."

While I don't feel quite that strongly about type casts, one use case for 
casting does bother me: Using a generic object as the type of a member, and 
then specializing the object when you use it.

A good example is a Token type in a lexer. The token typically has a line and 
column number, a string (the text of the token), a token type (an enumeration 
or int) and a value. The value is an integer for an integer token, a string for 
a string, an enum for a symbol or keyword, etc. So the type of the value field 
is "object", and you use the token type to tell you how to cast the value field 
when you use it.

The Lava solution to this problem is to allow an explicit type switch:

switch (value.type) {

case int:  // value is an int
value += 3;
break;

case string: // value is a string
string sub = substring(value, 1, 5);
break;

case symbol: // value is a symbol type
int index = value.getSymbolIndex;
break;

}

(Lava doesn't actually give an example of a type switch -- I just guessed at 
what it would look like.)

Anyone else think this is a good idea?

Does anyone know of another language that does this? (I don't have much 
knowledge of functional or logical languages.)

Paul



Re: type switch

2015-05-04 Thread Dennis Ritchie via Digitalmars-d

On Monday, 4 May 2015 at 22:48:37 UTC, Dennis Ritchie wrote:

Why not put in Phobos shorter design type switch:


*More precisely, not in Phobos and DMD.


Re: type switch

2015-05-05 Thread Ali Çehreli via Digitalmars-d

On 05/04/2015 03:48 PM, Dennis Ritchie wrote:

> I've been thinking. In D you can write a similar design to the generic
> functions or somewhere, use static if:
>
> // -
> static if (is(T == short) || is(T == int) || is(T == long)) {
>  // do anything
> } else static if (is(T == real)) {
>  // ...
> } else static if (is(T == char)) {
>  // ...
> } else static if (is(T == string)) {
>  // ...
> } else static if (is(T == int[])) {
>  // ...
> } else {
>  // ...
> }
>
> Why not put in Phobos shorter design type switch:
>
> // -
> type switch (T) {
> case short, int, long:
>  // do anything
> case real:
>  // ...
> case char:
>  // ...
> case string:
>  // ...
> case int[]:
>  // ...
> default:
>  // ...
> }
>
> This design has been implemented, for example, in Common Lisp (typecase):
> http://www.lispworks.com/documentation/lw51/CLHS/Body/m_tpcase.htm
>
> What do you think about this?

Personally, I haven't felt the need for this becuase usually there is 
something different only for one or two specific types.


I don't see that the syntax becomes shorter to warrant a language 
addition either. (However, the risk of writing 'else if' instead of 
'else static if' is a real annoyance that comes with bad consequences.)


Another option is to use template specializations, which can be mixed-in 
(in bar() below) or called directly (in foo() below):


void doSomethingSpecial(T : int)()
{
// ...
}

void doSomethingSpecial(T : string)()
{
// ...
}

void foo(T)()
{
doSomethingSpecial!T();
}

void bar(T)()
{
mixin doSomethingSpecial!T;
}

void main()
{
foo!string();
bar!int();
}

Ali



Re: type switch

2015-05-05 Thread Justin Whear via Digitalmars-d
How's this? http://dpaste.dzfl.pl/d6643ec8ccd3


Re: type switch

2015-05-05 Thread Dennis Ritchie via Digitalmars-d

On Tuesday, 5 May 2015 at 18:12:42 UTC, Ali Çehreli wrote:
Personally, I haven't felt the need for this becuase usually 
there is something different only for one or two specific types.


I don't see that the syntax becomes shorter to warrant a 
language addition either. (However, the risk of writing 'else 
if' instead of 'else static if' is a real annoyance that comes 
with bad consequences.)


Another option is to use template specializations, which can be 
mixed-in (in bar() below) or called directly (in foo() below):


void doSomethingSpecial(T : int)()
{
// ...
}

void doSomethingSpecial(T : string)()
{
// ...
}

void foo(T)()
{
doSomethingSpecial!T();
}

void bar(T)()
{
mixin doSomethingSpecial!T;
}

void main()
{
foo!string();
bar!int();
}

Ali


Maybe it will not much shorter, but in some cases, such a design 
would look more appropriate than static if.
In addition, the keyword "case" may be omitted in this design, 
which will make it even more short and readable. Such as here:

http://dpaste.dzfl.pl/d6643ec8ccd3

In my opinion, the implementation of such a structure will not 
hurt D. While it may be something I do not understand :)


Re: type switch

2015-05-05 Thread Dennis Ritchie via Digitalmars-d

On Tuesday, 5 May 2015 at 18:37:52 UTC, Justin Whear wrote:

How's this? http://dpaste.dzfl.pl/d6643ec8ccd3


Yes, something like that. In my opinion, it's really easier than 
static if in some cases.


Re: type switch

2009-09-01 Thread Jarrett Billingsley
On Tue, Sep 1, 2009 at 7:39 PM, Paul D.
Anderson wrote:
> I came across Lava, an experimental programming language ("What's hotter than 
> Java?") http://lavape.sourceforge.net/LavaHomePage.htm Lava has some curious 
> features (they claim to have no syntax, but the syntax is just hidden by the 
> "programming environment").
>
> One of the evils of other programming languages, according to the website, is 
> the infamous type cast: "Type casts are not only ugly, nasty, and annoying 
> but much worse: their justification can only be assessed on the basis of a 
> more comprehensive understanding of the dynamic program behavior in general."
>
> While I don't feel quite that strongly about type casts, one use case for 
> casting does bother me: Using a generic object as the type of a member, and 
> then specializing the object when you use it.
>
> A good example is a Token type in a lexer. The token typically has a line and 
> column number, a string (the text of the token), a token type (an enumeration 
> or int) and a value. The value is an integer for an integer token, a string 
> for a string, an enum for a symbol or keyword, etc. So the type of the value 
> field is "object", and you use the token type to tell you how to cast the 
> value field when you use it.
>
> The Lava solution to this problem is to allow an explicit type switch:
>
> switch (value.type) {
>
> case int:  // value is an int
>    value += 3;
>    break;
>
> case string: // value is a string
>    string sub = substring(value, 1, 5);
>    break;
>
> case symbol: // value is a symbol type
>    int index = value.getSymbolIndex;
>    break;
>
> }
>
> (Lava doesn't actually give an example of a type switch -- I just guessed at 
> what it would look like.)
>
> Anyone else think this is a good idea?
>
> Does anyone know of another language that does this? (I don't have much 
> knowledge of functional or logical languages.)

Just looks like simple pattern matching. It's very common in
functional languages.