www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How to complex switch?

reply Matthew Ong <ongbp yahoo.com> writes:
Hi All,

Anyway to include this cool feature of switch with D in the near future?

switch(str){
                   // regexp
case "abc", "def", "as+b?": s1(); break;

case "za+", "wd?", "aaa": s2(); break;

default: s3();
}

switch (tag) {
default: s3()
case 0, 1, 2, 3: s1()
case 4, 5, 6, 7: s2()
}

switch (x := f();) {  // missing switch expression means "true"
case x < 0: return -x
default: return x
}

switch (x){
case x < y: f1()
case x < z: f2()
case x == 4: f3()
case z+y: f4()
}
May 12 2011
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On May 12, 11 19:13, Matthew Ong wrote:

 Hi All,

 Anyway to include this cool feature of switch with D in the near future?


Why the obsession with 'switch'? 'if' works fine.


 switch(str){
                     // regexp
 case "abc", "def", "as+b?": s1(); break;

 case "za+", "wd?", "aaa": s2(); break;

 default: s3();
 }


Regex isn't even a built-in feature, why would a 'switch' should support it.

if (match(str, regex("abc|def|as+b?"))
   s1();
else if (match(str, regex("za+|wd?|aaa"))
   s2();
else
   s3();


 switch (tag) {
 default: s3()
 case 0, 1, 2, 3: s1()
 case 4, 5, 6, 7: s2()
 }


Already possible (except you're missing the 'break;')


 switch (x := f();) {  // missing switch expression means "true"
 case x<  0: return -x
 default: return x
 }


Please no. Why introduce yet another operator ':=' ?!

auto x = f();
if (x < 0)
   return -x;
else
   return x;


 switch (x){
 case x<  y: f1()
 case x<  z: f2()
 case x == 4: f3()
 case z+y: f4()
 }


Assume you don't mean to fall-through

if (x < y)
    f1();
else if (x < z)
    f2();
else if (x == 4)
    f3();
else if (x == z+y)
    f4();
May 12 2011
next sibling parent reply matthew ong <ongbp yahoo.com> writes:
Hi KennyTM~,

Some of the valid reason:
1) Less key stroke
2) Easier code generator to implement
3) Better to read.
4) less worries about braket '{'.
5) ....

In Java, C++ we avoided using switch because it ONLY support const & literal
type.

Most script base language supports things like this. I believe bash shell script
does. Since D aimed to be a next generation language,
I suppose that should be in with fall through also.
May 12 2011
next sibling parent Matthew Ong <ongbp yahoo.com> writes:
Sample Code of Bash left out in previous post.

----------------------------------------------------------------------
case $space in
[1-6]*) // <<< That if some sort of such logic can be supported in D.
  Message="All is quiet."
  ;;
[7-8]*)
  Message="Start thinking about cleaning out some stuff.  There's a partition
that
is $space % full."
  ;;
9[1-8])
  Message="Better hurry with that new disk...  One partition is $space % full."
  ;;
99)
  Message="I'm drowning here!  There's a partition at $space %!"
  ;;
*)
  Message="I seem to be running with an nonexistent amount of disk space..."
  ;;
esac
May 12 2011
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
On May 12, 11 20:04, matthew ong wrote:

 Hi KennyTM~,

 Some of the valid reason:
 1) Less key stroke


Invalid,

switch (x = f()) {
   case x < 0: return -x
   default: return x
}

50 significant characters

auto x = f();
if (x < 0) return -x;
else       return x;

41 significant characters


 2) Easier code generator to implement


Invalid. Both share the same structure.

     switch (x = <variable>) {
        case <condition>: <statements> break;
        case <condition>: <statements> break;
        default:          <statements> break;
     }

     auto x = <variable>;
          if (<condition>) { <statements>; }
     else if (<condition>) { <statements>; }
     else                  { <statements>; }


 3) Better to read.


I don't think so.


 4) less worries about braket '{'.


More worries about missing 'break;' (bad C heritage)


 5) ....


....


 In Java, C++ we avoided using switch because it ONLY support const&  literal
type.


D also only supports literals types. A 'switch' statement is often 
implemented as a look-up table when compiled, so keeping the cases a 
compile-time constant helps to generate more efficient code. If you can 
supply an arbitrary condition or a regex, this advantage is lost and 
it's no better than a if/else-if/else chain.


 Most script base language supports things like this. I believe bash shell
script
 does. Since D aimed to be a next generation language,
 I suppose that should be in with fall through also.


No one forced a "next generation language" have to have a 'switch' with 
conditional or regex cases. Look, Python 3 doesn't even have a 'switch'.
May 12 2011
prev sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 5/12/11 6:42 PM, KennyTM~ wrote:

 On May 12, 11 19:13, Matthew Ong wrote:

 Hi All,

 Anyway to include this cool feature of switch with D in the near future?


 Why the obsession with 'switch'? 'if' works fine.


 switch(str){
 // regexp
 case "abc", "def", "as+b?": s1(); break;

 case "za+", "wd?", "aaa": s2(); break;

 default: s3();
 }


 Regex isn't even a built-in feature, why would a 'switch' should support
 it.


How about making regex a built-in feature with this syntax: /regex/ ?

I didn't use regex a lot before I started using Ruby. The thing is, in 
Ruby it's so easy to use regex that I just started using them a lot more 
than before. Of course, ruby has built-in operators for matching regexs, 
so maybe that should also be added to the language (it's the =~ 
operator, but in D it should be a different one.)
May 12 2011
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On May 13, 11 12:14, Ary Manzana wrote:

 On 5/12/11 6:42 PM, KennyTM~ wrote:

 On May 12, 11 19:13, Matthew Ong wrote:

 Hi All,

 Anyway to include this cool feature of switch with D in the near future?


 Why the obsession with 'switch'? 'if' works fine.


 switch(str){
 // regexp
 case "abc", "def", "as+b?": s1(); break;

 case "za+", "wd?", "aaa": s2(); break;

 default: s3();
 }


 Regex isn't even a built-in feature, why would a 'switch' should support
 it.


 How about making regex a built-in feature with this syntax: /regex/ ?

 I didn't use regex a lot before I started using Ruby. The thing is, in
 Ruby it's so easy to use regex that I just started using them a lot more
 than before. Of course, ruby has built-in operators for matching regexs,
 so maybe that should also be added to the language (it's the =~
 operator, but in D it should be a different one.)


IIRC it was once there, but very soon removed in the 0.x era (can't find 
that changelog). You can't distinguish between division and regex 
literal in the parser with this syntax.

See:
  - http://www.digitalmars.com/d/2.0/faq.html#regexp_literals
  - http://www.digitalmars.com/d/2.0/regular-expression.html
May 12 2011
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 5/13/11 12:10 PM, KennyTM~ wrote:

 On May 13, 11 12:14, Ary Manzana wrote:

 On 5/12/11 6:42 PM, KennyTM~ wrote:

 On May 12, 11 19:13, Matthew Ong wrote:

 Hi All,

 Anyway to include this cool feature of switch with D in the near
 future?


 Why the obsession with 'switch'? 'if' works fine.


 switch(str){
 // regexp
 case "abc", "def", "as+b?": s1(); break;

 case "za+", "wd?", "aaa": s2(); break;

 default: s3();
 }


 Regex isn't even a built-in feature, why would a 'switch' should support
 it.


 How about making regex a built-in feature with this syntax: /regex/ ?

 I didn't use regex a lot before I started using Ruby. The thing is, in
 Ruby it's so easy to use regex that I just started using them a lot more
 than before. Of course, ruby has built-in operators for matching regexs,
 so maybe that should also be added to the language (it's the =~
 operator, but in D it should be a different one.)


 IIRC it was once there, but very soon removed in the 0.x era (can't find
 that changelog). You can't distinguish between division and regex
 literal in the parser with this syntax.


Ruby can do it. I'm a happier programmer this way. If you don't support 
it in the language the compiler is happy and the user is sad. :-( But 
the user is more important than the compiler...
May 13 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-13 14:59, Ary Manzana wrote:

 On 5/13/11 12:10 PM, KennyTM~ wrote:

 On May 13, 11 12:14, Ary Manzana wrote:

 On 5/12/11 6:42 PM, KennyTM~ wrote:

 On May 12, 11 19:13, Matthew Ong wrote:

 Hi All,

 Anyway to include this cool feature of switch with D in the near
 future?


 Why the obsession with 'switch'? 'if' works fine.


 switch(str){
 // regexp
 case "abc", "def", "as+b?": s1(); break;

 case "za+", "wd?", "aaa": s2(); break;

 default: s3();
 }


 Regex isn't even a built-in feature, why would a 'switch' should
 support
 it.


 How about making regex a built-in feature with this syntax: /regex/ ?

 I didn't use regex a lot before I started using Ruby. The thing is, in
 Ruby it's so easy to use regex that I just started using them a lot more
 than before. Of course, ruby has built-in operators for matching regexs,
 so maybe that should also be added to the language (it's the =~
 operator, but in D it should be a different one.)


 IIRC it was once there, but very soon removed in the 0.x era (can't find
 that changelog). You can't distinguish between division and regex
 literal in the parser with this syntax.


 Ruby can do it. I'm a happier programmer this way. If you don't support
 it in the language the compiler is happy and the user is sad. :-( But
 the user is more important than the compiler...


I'm pretty sure this is a big reason:

"Regular expression literal syntax - doing so would make it impossible 
to perform lexical analysis without also doing syntactic or semantic 
analysis."

From: http://www.digitalmars.com/d/2.0/regular-expression.html

-- 
/Jacob Carlborg
May 15 2011
parent Matthew Ong <ongbp yahoo.com> writes:
Hi,

Seems like some people also had the same idea about D supporting more complex
switch syntax and given more interesting reasons.

Perhaps can be consider for D 3.0 or ...

I am new here, please understand, but wish to see D take off because I
do see some nice syntax in D.
May 16 2011
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 13/05/2011 06:10, KennyTM~ wrote:

 On May 13, 11 12:14, Ary Manzana wrote:


<snip>

 I didn't use regex a lot before I started using Ruby. The thing is, in
 Ruby it's so easy to use regex that I just started using them a lot more
 than before. Of course, ruby has built-in operators for matching regexs,
 so maybe that should also be added to the language (it's the =~
 operator, but in D it should be a different one.)


 IIRC it was once there, but very soon removed in the 0.x era (can't find that
changelog).


There was a builtin regexp feature added in 0.147 - I think it was a ~~ or =~
operator 
with a string either side.  I'm not sure whether it broke too much existing
code or was 
just thought not right as a language builtin, but it was dropped again in 0.148.


 You can't distinguish between division and regex literal in the parser with
this syntax.


And that's half the reason such a syntax has never been implemented in D.


 See:
 - http://www.digitalmars.com/d/2.0/faq.html#regexp_literals
 - http://www.digitalmars.com/d/2.0/regular-expression.html


Which ignores the idea of using a different notation for regexp literals. 
Though it's 
probably not worth much debate when the idea of a built-in regexp type has been
rejected 
as language bloat.

I think D is going the right way on the whole by leaving regexps to a library. 
Though 
this does limit such possibilities as optimised regexp switches.

Stewart.
May 17 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Stewart Gordon:


 I think D is going the right way on the whole by leaving regexps to a library.
 Though 
 this does limit such possibilities as optimised regexp switches.


Leaving regexps to a library is an acceptable choice for D, or maybe even the
best choice. In D even associative arrays are not so important as builtins, you
just need literals for associative arrays.

On the other hand my experience shows me some other things are better as
builtins (or partial built-ins), as tuples. I'd like unpacking syntax sugar for
tuples, to be used inside foreach too, and as recently emerged in D.learn, some
better cast for tuples (to allow conversion of slightly differently typed
tuples, and structural typing).

Tuples are a general language construct, useful in many situations for many
different purposes, they are _much_ more commonly useful than regex. I use some
regex most Python scripts that processes lot of text, but I use tuples every
4-5 lines of code or less :-) And indeed, in Python too regexes are not
built-in, while tuples are.

Bye,
bearophile
May 17 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
 Stewart Gordon:


 I think D is going the right way on the whole by leaving regexps to a library.




 Though

 this does limit such possibilities as optimised regexp switches.


 Leaving regexps to a library is an acceptable choice for D, or maybe even the


best choice. In D even associative arrays are not so important as builtins, you
just need literals for associative arrays.


 On the other hand my experience shows me some other things are better as


builtins (or partial built-ins), as tuples. I'd like unpacking syntax sugar for
tuples, to be used inside foreach too, and as recently emerged in D.learn, some
better cast for tuples (to allow conversion of slightly differently typed
tuples,
and structural typing).


 Tuples are a general language construct, useful in many situations for many


different purposes, they are _much_ more commonly useful than regex. I use some
regex most Python > scripts that processes lot of text, but I use tuples every
4-5
lines of code or less :-) And indeed, in Python too regexes are not built-in,
while tuples are.

 Bye,
 bearophile


Tuple literals would indeed be very nice. This _would_ mean that tuples get
entirely built-in (having syntactic sugar for phobos functionality in the
language
seems like a very bad design to me, it would at least have to be copied/moved to
druntime).

However, tuple literals break the comma operator...

But who would write something like
?
auto t=(1,2,3);

anyway in serious code? (where "," means comma operator).

Therefore Tuple literals could be introduced by a minor change in the grammar,
where uses of the comma operator like

return a=2,b=3; would still work normally.

What would be the type of such a tuple literal? (T,T,T,...)?

I don't expect something like this to be implemented soon though.

Timon
May 17 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:


 Tuple literals would indeed be very nice.


I have asked for tuple unpacking syntax (and other things like some support
from the type system). Tuple literals are less needed.



 (having syntactic sugar for phobos functionality in the language
 seems like a very bad design to me,


I don't see it as a bad design. Why do you see it as a bad thing?



 However, tuple literals break the comma operator...


If something like a banana bracket syntax (|...|) is required (or some other
kind of thing), then I think it doesn't clash with C usages of comma operator.



 What would be the type of such a tuple literal? (T,T,T,...)?


I presume Tuple!(int, int, int)



 I don't expect something like this to be implemented soon though.


Stuff like this requires months of thinking, and just few days to be
implemented by Walter :-)

Bye,
bearophile
May 17 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
 Timon Gehr:


 Tuple literals would indeed be very nice.


 I have asked for tuple unpacking syntax (and other things like some support
from


the type system). Tuple literals are less needed.

 (having syntactic sugar for phobos functionality in the language
 seems like a very bad design to me,


 I don't see it as a bad design. Why do you see it as a bad thing?


Library code should make use of the language to implement its semantics.
Not the other way round. They also screwed this up in C++0x with
std::initializer_list;


 However, tuple literals break the comma operator...


 If something like a banana bracket syntax (|...|) is required (or some other


kind of thing), then I think it doesn't clash with C usages of comma operator.

It does not clash with any other language feature because it is too ugly to have
been considered as syntax for another language feature :). imho it would not be
syntactic sugar anymore, that looks awful and is awful to type. Just my opinion
though. Another reason I dislike it: it looks different to other "tuple
literals"
that are already built-in:

foo (note, how, this, is, a, tuple, "!");


 What would be the type of such a tuple literal? (T,T,T,...)?


 I presume Tuple!(int, int, int)


It would have to be a built-in type. (Even if it is internally just implemented
as
Tuple hanging around in druntime).


 I don't expect something like this to be implemented soon though.


 Stuff like this requires months of thinking, and just few days to be
implemented


by Walter :-)

If it is just some simple rewrites it should indeed be possible to implement it
quite fast. Still, I think (|1,2,3|) is not optimal.

Maybe the best way to resolve it would be to allow some special symbol as an
identifier, so that the library/user could make that symbol an alias of "tuple".
It would have to be a very small symbol, are there any suitable symbols that are
not yet taken?



 Bye,
 bearophile


Timon
May 18 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:


 Library code should make use of the language to implement its semantics.
 Not the other way round.


Why?



 Another reason I dislike it: it looks different to other "tuple literals"
 that are already built-in:
 
 foo (note, how, this, is, a, tuple, "!");


Looking different from the built-in ones was the point of it, to avoid clashes.



 Still, I think (|1,2,3|) is not optimal.


Please, invent better things :-)

Bye,
bearophile
May 18 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
 Timon Gehr:


 Library code should make use of the language to implement its semantics.
 Not the other way round.


 Why?


Short story: Obvious?

Do you really want to make some non-built-in types more equal than others? Why
would you want to have a dependency cycle between std and the compiler?

Longer story: You get all the drawbacks of a library-based solution except
literal
syntax (a one-character alias for tuple can already make up much of it without
work from the compiler so your benefit is basically zero).

But you want improved return type deduction, many will want tuple assignments in
the style (a,b)=(b-a,a+b), etc. tuple cannot do it. Therefore the part the
compiler takes will get so large that in the end the only relict of the library
stuff will be that you have to import std.typecons; or else you will get some
strange errors that do not at all look like your code. (Or even more silly, the
compiler will directly nag you "Did you forget to import std.typecons?"). The
question is, do you want to import typecons or not. It is just that and
furthermore a question of clean design.

How tuples are handled internally should be a compiler/runtime thing, not a
standard library thing. I would be fine with Tuple!(T) defining conversions from
and to the built-in tuple.


 Another reason I dislike it: it looks different to other "tuple literals"
 that are already built-in:

 foo (note, how, this, is, a, tuple, "!");


 Looking different from the built-in ones was the point of it, to avoid clashes.


No. There is no way it could clash with foo (a,b,c).

The only use case where the straightforward solution would clash is something
like
this:

auto a=(i++,j++,k++);

Nobody who is sane writes such code!


 Still, I think (|1,2,3|) is not optimal.


 Please, invent better things :-)


1. Deprecate using CommaExpression inside ParanthesizedExpression. (This does
not
affect most code that uses the comma operator!)
2. Wait a few releases.
3. Introduce straightforward, built-in tuples:

auto t=(1,"string",'c');
auto (i,s,c)=t; //Tuple!(int,string,char) cannot do this. Maybe there is a
better
syntax for type inference, but I think this one it quite good.

(auto x,auto y,auto d) s=(1,2,3.0);
//... (can use s.x, s.y and s.d now)

writeln(i," ",s," ",c);

(string,) t=("this is a one-element tuple",);

(int,int,int) q=(1,2,3);
int[3] arr=q; //should be allowed in both directions, because arrays are
basically
special cases of tuples. function calls already reflect this.

Other semantics could be similar to Tuple!(T). Maybe I missed some obvious
feature. In that case, include that too. :)


 Bye,
 bearophile



Timon
May 18 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/18/11 5:12 PM, Timon Gehr wrote:

 Timon Gehr:


 Library code should make use of the language to implement its semantics.
 Not the other way round.


 Why?


 Short story: Obvious?

 Do you really want to make some non-built-in types more equal than others? Why
 would you want to have a dependency cycle between std and the compiler?

 Longer story: You get all the drawbacks of a library-based solution except
literal
 syntax (a one-character alias for tuple can already make up much of it without
 work from the compiler so your benefit is basically zero).

 But you want improved return type deduction, many will want tuple assignments
in
 the style (a,b)=(b-a,a+b), etc. tuple cannot do it. Therefore the part the
 compiler takes will get so large that in the end the only relict of the library
 stuff will be that you have to import std.typecons; or else you will get some
 strange errors that do not at all look like your code. (Or even more silly, the
 compiler will directly nag you "Did you forget to import std.typecons?"). The
 question is, do you want to import typecons or not. It is just that and
 furthermore a question of clean design.

 How tuples are handled internally should be a compiler/runtime thing, not a
 standard library thing. I would be fine with Tuple!(T) defining conversions
from
 and to the built-in tuple.


 Another reason I dislike it: it looks different to other "tuple literals"
 that are already built-in:

 foo (note, how, this, is, a, tuple, "!");


 Looking different from the built-in ones was the point of it, to avoid clashes.


 No. There is no way it could clash with foo (a,b,c).

 The only use case where the straightforward solution would clash is something
like
 this:

 auto a=(i++,j++,k++);

 Nobody who is sane writes such code!


 Still, I think (|1,2,3|) is not optimal.


 Please, invent better things :-)


 1. Deprecate using CommaExpression inside ParanthesizedExpression. (This does
not
 affect most code that uses the comma operator!)
 2. Wait a few releases.
 3. Introduce straightforward, built-in tuples:


[snip]

We've been thinking of this approach but it would be difficult to pull off.

One possibility that I hadn't thought before is to use ";" for 
separating tuple elements. Upon a casual inspection, it turns out no 
statement can be enclosed directly in "(" and ")" so there's no 
ambiguity. It would also take care of the issue "did you mean to pass 
them as function arguments, or as one tuple argument?" Just a thought...

auto t=(1; "string"; 'c');

Ehm.

Andrei
May 18 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 One possibility that I hadn't thought before is to use ";" for 
 separating tuple elements. Upon a casual inspection, it turns out no 
 statement can be enclosed directly in "(" and ")" so there's no 
 ambiguity. It would also take care of the issue "did you mean to pass 
 them as function arguments, or as one tuple argument?" Just a thought...
 
 auto t=(1; "string"; 'c');


If this works, then I like it. In the end having some syntas, any syntax, for
tuples is better than not being able to do things like:
auto (foo; bar; _) = spam();
foreach ((a;b); iter1()) {}
int foo(xy (int x; int y)) { writeln(x, " ", y, " ", xy); // naming whole tuple
too
(int x; int y) = (1U; 2U); // conversions


Partially related note: currently this code:

import std.stdio, std.range;
void main() {
    writeln([0, 1, 2, 3, 4]);
    writeln(iota(5));
}

Prints:
[0, 1, 2, 3, 4]
[0, 1, 2, 3, 4]

In Bugzilla I have argued it to print instead:
[0, 1, 2, 3, 4]
[0; 1; 2; 3; 4]

To allow the person that reads the output to better tell apart arrays from lazy
sequences.

Thank you,
bearophile
May 18 2011
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
Andrei Alexandrescu wrote:

 Timon Gehr wrote:

 1. Deprecate using CommaExpression inside ParanthesizedExpression. (This does
not
 affect most code that uses the comma operator!)
 2. Wait a few releases.
 3. Introduce straightforward, built-in tuples:


 [snip]

 We've been thinking of this approach but it would be difficult to pull off.


How would it be difficult to realize? I guess there is literally no serious D
code
out there that uses anything that could clash with tuple literals. (And if there
is any - it can easily be rewritten to use inline delegates instead...)

It should also be only a minor change in the grammar.


 One possibility that I hadn't thought before is to use ";" for
 separating tuple elements. Upon a casual inspection, it turns out no
 statement can be enclosed directly in "(" and ")" so there's no
 ambiguity. It would also take care of the issue "did you mean to pass
 them as function arguments, or as one tuple argument?" Just a thought...


other possibilites:

1. make tuple expansion explicit. //maybe not too great as the built-in
TypeTuple
expands by default.
2. use the same convention as that used for one-element tuples.

void foo(int a,int b,int c);    //1
void foo((int,int,int) t,); //2

auto t=(1,2,3);
foo(t);  //calls 1 (since t is expanded)
foo(t,); //calls 2 (t is not expanded)

This would change the meaning of trailing "," when tuples are involved though.


 auto t=(1; "string"; 'c');


I have actually considered that too. Some issues:

1. ";" is not as easy to type as "," on many keyboard layouts. (not everybody
will
use a US Keyboard)
2. It is, like "(|1,2,3|)" another syntax for the same thing that is already
present in the language, (template) parameter tuples. Furthermore, Array and
AssocArray both use "," as a delimiter, meaning it would add further
inconsistency. I think tuple literals should build up on existing features, not
be
orthogonal to them. imho tuple literals are a logical consequence of
generalizing
D's design, not an entirely new feature.
3. Most important: Error messages. If ";" is not guaranteed to be a statement
delimiter, writing a compiler that can generate meaningful error messages is
_much_ more difficult!


 Ehm.

 Andrei



Timon
May 19 2011
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 13/05/2011 05:14, Ary Manzana wrote:

 How about making regex a built-in feature with this syntax: /regex/ ?

 I didn't use regex a lot before I started using Ruby. The thing is, in
 Ruby it's so easy to use regex that I just started using them a lot more
 than before. Of course, ruby has built-in operators for matching regexs,
 so maybe that should also be added to the language (it's the =~
 operator, but in D it should be a different one.)


Regex is ugly, impossible to maintain/debug and slow for anything mildly 
complicated - a handwritten parser is magnitudes faster, and easy to 
understand, maintain and debug. If it's simple, you may as well write a 
couple of extra lines and have it be a lot faster.

Just my opinion of course, I know you're bound to disagree :>

-- 
Robert
http://octarineparrot.com/
May 13 2011
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 13.05.2011 18:25, Robert Clipsham wrote:

 On 13/05/2011 05:14, Ary Manzana wrote:

 How about making regex a built-in feature with this syntax: /regex/ ?

 I didn't use regex a lot before I started using Ruby. The thing is, in
 Ruby it's so easy to use regex that I just started using them a lot more
 than before. Of course, ruby has built-in operators for matching regexs,
 so maybe that should also be added to the language (it's the =~
 operator, but in D it should be a different one.)


 Regex is ugly, impossible to maintain/debug and slow for anything 
 mildly complicated - a handwritten parser is magnitudes faster, and 
 easy to understand, maintain and debug. If it's simple, you may as 
 well write a couple of extra lines and have it be a lot faster.


Handwritten parser is faster, but hard to get right, port or maintain. 
Also handwritten parser has almost zero flexibility - patching it to 
accommodate new kinds of input is PITA.
Regexes on the other hand are widely known DSL for pattern matching, 
which IMO easier to get right, port across languages and platforms (with 
caveats). Flexibility - regex engines in a way are just simple parser 
generators with some bells and whistles. And BTW they could be quite 
fast (depending on the use case, of course).


 Just my opinion of course, I know you're bound to disagree :>


Probably you never faced problems like "get me some info from these 
<enter your gazillon number> simple reports/emails/etc." All things that 
don't follow some formal language enjoy flexibility on the parser side. 
E.g. you can patch together through try/trial cycle a couple of 
aproximate regexes and have very reasonable results in no time.

The real pitfall of regexes vs handcrafted parsers is that they can't 
match important classes of problems like: "the innermost parenthesized 
expression in a given string" and such.

-- 
Dmitry Olshansky
May 13 2011
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On May 13, 11 23:12, Dmitry Olshansky wrote:

 On 13.05.2011 18:25, Robert Clipsham wrote:

 On 13/05/2011 05:14, Ary Manzana wrote:

 How about making regex a built-in feature with this syntax: /regex/ ?

 I didn't use regex a lot before I started using Ruby. The thing is, in
 Ruby it's so easy to use regex that I just started using them a lot more
 than before. Of course, ruby has built-in operators for matching regexs,
 so maybe that should also be added to the language (it's the =~
 operator, but in D it should be a different one.)


 Regex is ugly, impossible to maintain/debug and slow for anything
 mildly complicated - a handwritten parser is magnitudes faster, and
 easy to understand, maintain and debug. If it's simple, you may as
 well write a couple of extra lines and have it be a lot faster.


 Handwritten parser is faster, but hard to get right, port or maintain.
 Also handwritten parser has almost zero flexibility - patching it to
 accommodate new kinds of input is PITA.
 Regexes on the other hand are widely known DSL for pattern matching,
 which IMO easier to get right, port across languages and platforms (with
 caveats). Flexibility - regex engines in a way are just simple parser
 generators with some bells and whistles. And BTW they could be quite
 fast (depending on the use case, of course).


 Just my opinion of course, I know you're bound to disagree :>


 Probably you never faced problems like "get me some info from these
 <enter your gazillon number> simple reports/emails/etc." All things that
 don't follow some formal language enjoy flexibility on the parser side.
 E.g. you can patch together through try/trial cycle a couple of
 aproximate regexes and have very reasonable results in no time.

 The real pitfall of regexes vs handcrafted parsers is that they can't
 match important classes of problems like: "the innermost parenthesized
 expression in a given string" and such.


Nitpick: *Innermost* parenthesized expression can be parsed easily with 
regex (r"\([^)]*\)"). Outermost would be difficult.
May 13 2011
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 13.05.2011 19:26, KennyTM~ wrote:

 On May 13, 11 23:12, Dmitry Olshansky wrote:

 On 13.05.2011 18:25, Robert Clipsham wrote:

 On 13/05/2011 05:14, Ary Manzana wrote:

 How about making regex a built-in feature with this syntax: /regex/ ?

 I didn't use regex a lot before I started using Ruby. The thing is, in
 Ruby it's so easy to use regex that I just started using them a lot 
 more
 than before. Of course, ruby has built-in operators for matching 
 regexs,
 so maybe that should also be added to the language (it's the =~
 operator, but in D it should be a different one.)


 Regex is ugly, impossible to maintain/debug and slow for anything
 mildly complicated - a handwritten parser is magnitudes faster, and
 easy to understand, maintain and debug. If it's simple, you may as
 well write a couple of extra lines and have it be a lot faster.


 Handwritten parser is faster, but hard to get right, port or maintain.
 Also handwritten parser has almost zero flexibility - patching it to
 accommodate new kinds of input is PITA.
 Regexes on the other hand are widely known DSL for pattern matching,
 which IMO easier to get right, port across languages and platforms (with
 caveats). Flexibility - regex engines in a way are just simple parser
 generators with some bells and whistles. And BTW they could be quite
 fast (depending on the use case, of course).


 Just my opinion of course, I know you're bound to disagree :>


 Probably you never faced problems like "get me some info from these
 <enter your gazillon number> simple reports/emails/etc." All things that
 don't follow some formal language enjoy flexibility on the parser side.
 E.g. you can patch together through try/trial cycle a couple of
 aproximate regexes and have very reasonable results in no time.

 The real pitfall of regexes vs handcrafted parsers is that they can't
 match important classes of problems like: "the innermost parenthesized
 expression in a given string" and such.


 Nitpick: *Innermost* parenthesized expression can be parsed easily 
 with regex (r"\([^)]*\)"). Outermost would be difficult.


Yeah, I certainly meant outermost ;)

-- 
Dmitry Olshansky
May 13 2011
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 13.05.2011 19:35, Dmitry Olshansky wrote:

 On 13.05.2011 19:26, KennyTM~ wrote:

 On May 13, 11 23:12, Dmitry Olshansky wrote:

 On 13.05.2011 18:25, Robert Clipsham wrote:

 On 13/05/2011 05:14, Ary Manzana wrote:

 How about making regex a built-in feature with this syntax: /regex/ ?

 I didn't use regex a lot before I started using Ruby. The thing 
 is, in
 Ruby it's so easy to use regex that I just started using them a 
 lot more
 than before. Of course, ruby has built-in operators for matching 
 regexs,
 so maybe that should also be added to the language (it's the =~
 operator, but in D it should be a different one.)


 Regex is ugly, impossible to maintain/debug and slow for anything
 mildly complicated - a handwritten parser is magnitudes faster, and
 easy to understand, maintain and debug. If it's simple, you may as
 well write a couple of extra lines and have it be a lot faster.


 Handwritten parser is faster, but hard to get right, port or maintain.
 Also handwritten parser has almost zero flexibility - patching it to
 accommodate new kinds of input is PITA.
 Regexes on the other hand are widely known DSL for pattern matching,
 which IMO easier to get right, port across languages and platforms 
 (with
 caveats). Flexibility - regex engines in a way are just simple parser
 generators with some bells and whistles. And BTW they could be quite
 fast (depending on the use case, of course).


 Just my opinion of course, I know you're bound to disagree :>


 Probably you never faced problems like "get me some info from these
 <enter your gazillon number> simple reports/emails/etc." All things 
 that
 don't follow some formal language enjoy flexibility on the parser side.
 E.g. you can patch together through try/trial cycle a couple of
 aproximate regexes and have very reasonable results in no time.

 The real pitfall of regexes vs handcrafted parsers is that they can't
 match important classes of problems like: "the innermost parenthesized
 expression in a given string" and such.


 Nitpick: *Innermost* parenthesized expression can be parsed easily 
 with regex (r"\([^)]*\)"). Outermost would be difficult.


 Yeah, I certainly meant outermost ;)


Actually, wait a sec...
r"\([^)]*\)" won't help :
(a+(b+c)+d)
matches:
(a+(b+c) which is not intended...
r"\([^()]*\)" should do the trick

-- 
Dmitry Olshansky
May 13 2011
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 13/05/2011 16:12, Dmitry Olshansky wrote:

 Regex is ugly, impossible to maintain/debug and slow for anything
 mildly complicated - a handwritten parser is magnitudes faster, and
 easy to understand, maintain and debug. If it's simple, you may as
 well write a couple of extra lines and have it be a lot faster.


 Handwritten parser is faster, but hard to get right, port or maintain.
 Also handwritten parser has almost zero flexibility - patching it to
 accommodate new kinds of input is PITA.


When you've written a couple it doesn't take much to get it right in my 
experience. I don't find them hard to maintain personally, I guess that 
comes from experience though. What do you mean port?

As for patching for new input, that's a doddle if it's well written. 
Changing a regex on the other hand... It's generally easier to write it 
from scratch than decipher a current one.


 Regexes on the other hand are widely known DSL for pattern matching,
 which IMO easier to get right, port across languages and platforms (with
 caveats). Flexibility - regex engines in a way are just simple parser
 generators with some bells and whistles. And BTW they could be quite
 fast (depending on the use case, of course).


Of course, I don't feel that grants them a place in the language though. 
Particularly with the likes of octal! - it can quite easily be in a 
library and work just as well.


 Just my opinion of course, I know you're bound to disagree :>


 Probably you never faced problems like "get me some info from these
 <enter your gazillon number> simple reports/emails/etc." All things that
 don't follow some formal language enjoy flexibility on the parser side.
 E.g. you can patch together through try/trial cycle a couple of
 aproximate regexes and have very reasonable results in no time.


I have, and I use regex for it. Those kinda things just need a quick 
hack, and that's how I treat regex. If I'm doing anything that's getting 
used in production code/anything that isn't intended to be a hack I 
write a proper parser.


 The real pitfall of regexes vs handcrafted parsers is that they can't
 match important classes of problems like: "the innermost parenthesized
 expression in a given string" and such.


KennyTM~ gave you regex for that, providing you mean outermost - 
\((.+)\) will do it. Somewhere inbetween is harder, but doable if I 
recall correctly. But yes, there is a whole class of problems regex 
can't solve. The real pitfall for me is how difficult it is to 
decypher/debug.

-- 
Robert
http://octarineparrot.com/
May 13 2011
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 13.05.2011 20:00, Robert Clipsham wrote:

 On 13/05/2011 16:12, Dmitry Olshansky wrote:

 Regex is ugly, impossible to maintain/debug and slow for anything
 mildly complicated - a handwritten parser is magnitudes faster, and
 easy to understand, maintain and debug. If it's simple, you may as
 well write a couple of extra lines and have it be a lot faster.


 Handwritten parser is faster, but hard to get right, port or maintain.
 Also handwritten parser has almost zero flexibility - patching it to
 accommodate new kinds of input is PITA.


 When you've written a couple it doesn't take much to get it right in 
 my experience. I don't find them hard to maintain personally, I guess 
 that comes from experience though. What do you mean port?


Literally code the same in another programming language. Suppose there 
are going to be other programs working with the same data in similar ways.


 As for patching for new input, that's a doddle if it's well written. 
 Changing a regex on the other hand... It's generally easier to write 
 it from scratch than decipher a current one.


I see, the deciphering could really get tricky. As for rewriting from 
scratch that's something you generally try hard to avoid with 
handwritten stuff.


 Regexes on the other hand are widely known DSL for pattern matching,
 which IMO easier to get right, port across languages and platforms (with
 caveats). Flexibility - regex engines in a way are just simple parser
 generators with some bells and whistles. And BTW they could be quite
 fast (depending on the use case, of course).


 Of course, I don't feel that grants them a place in the language 
 though. Particularly with the likes of octal! - it can quite easily be 
 in a library and work just as well.


Sure thing it shouldn't be built it. D isn't awk.

 Just my opinion of course, I know you're bound to disagree :>


 Probably you never faced problems like "get me some info from these
 <enter your gazillon number> simple reports/emails/etc." All things that
 don't follow some formal language enjoy flexibility on the parser side.
 E.g. you can patch together through try/trial cycle a couple of
 aproximate regexes and have very reasonable results in no time.


 I have, and I use regex for it. Those kinda things just need a quick 
 hack, and that's how I treat regex. If I'm doing anything that's 
 getting used in production code/anything that isn't intended to be a 
 hack I write a proper parser.


Ok, so I think we can agree on the simple fact that there are things 
that just do not worth handwritten parser.

 The real pitfall of regexes vs handcrafted parsers is that they can't
 match important classes of problems like: "the innermost parenthesized
 expression in a given string" and such.


 KennyTM~ gave you regex for that, providing you mean outermost - 
 \((.+)\) will do it. 


Like I said, it's funny but it really can't do a lot with braces in 
general. It even fails to check balanced braces(of arbitrary depth).
Yours \((.+)\)   fails with
(a+b*c) + ((a*b)+c)
the _parenthesized expression_ here is "((A*B+C)" not "(a+b*c) + 
((a*b)+c)" (It's an expression? - yes. It's parenthesized? - no)


 Somewhere inbetween is harder, but doable if I recall correctly. But 
 yes, there is a whole class of problems regex can't solve. The real 
 pitfall for me is how difficult it is to decypher/debug.


-- 
Dmitry Olshansky
May 13 2011
parent Robert Clipsham <robert octarineparrot.com> writes:
On 13/05/2011 17:52, Dmitry Olshansky wrote:

 When you've written a couple it doesn't take much to get it right in
 my experience. I don't find them hard to maintain personally, I guess
 that comes from experience though. What do you mean port?


 Literally code the same in another programming language. Suppose there
 are going to be other programs working with the same data in similar ways.


extern(C) - you can now access it with C/C++, and D has bindings for a 
good few scripting languages! Why rewrite your code in another language 
at all? :D


 As for patching for new input, that's a doddle if it's well written.
 Changing a regex on the other hand... It's generally easier to write
 it from scratch than decipher a current one.


 I see, the deciphering could really get tricky. As for rewriting from
 scratch that's something you generally try hard to avoid with
 handwritten stuff.


You generally don't need to rewrite it when it's hand written, just 
tweak it.


 Of course, I don't feel that grants them a place in the language
 though. Particularly with the likes of octal! - it can quite easily be
 in a library and work just as well.


 Sure thing it shouldn't be built it. D isn't awk.


Glad we agree!


 I have, and I use regex for it. Those kinda things just need a quick
 hack, and that's how I treat regex. If I'm doing anything that's
 getting used in production code/anything that isn't intended to be a
 hack I write a proper parser.


 Ok, so I think we can agree on the simple fact that there are things
 that just do not worth handwritten parser.


Of course.

-- 
Robert
http://octarineparrot.com/
May 14 2011
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 12.05.2011 13:13, schrieb Matthew Ong:

 Hi All,


just a question - did you thought about that longer then 1 minute?

what real problem does this syntactic sugare solves?
May 12 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
 dennis luehring


just a question - did you thought about that longer then 1 minute?
what real problem does this syntactic sugare solves?


I do not think that this is syntactic sugar. Compare this 2 block of code. Which
is easier to read? I am not asking the level to be at bash
shell script, (that would be great).
Hopefully you get the idea that I am trying to communicate here. switch compare
to
if-else-chain is better to write and also avoided the
compilation error.

 KennyTM~:
:= sorry, it should not have been there. Typo error.


 switch(str){
                     // regexp
 case "abc", "def", "as+b?": s1(); break;

 case "za+", "wd?", "aaa": s2(); break;

 default: s3();
 }


----------------------------------------------------------------------
if (match(str, regex("abc|def|as+b?")) {
   s1();
}else if (match(str, regex("za+|wd?|aaa")){ // a lot of () and | ... might have
missed out one of them
   s2();
}else{
   s3()
}


----------------------------------------------------------------------
May 12 2011
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 12.05.2011 14:21, schrieb Matthew Ong:

  dennis luehring


----------------------------------------------------------------

 if (match(str, regex("abc|def|as+b?")) {
     s1();
 }else if (match(str, regex("za+|wd?|aaa")){ // a lot of () and | ... might have
 missed out one of them
     s2();
 }else{
     s3()
 }


ok, but how many times you suffering of masses of this code - and what 
happens if (normaly) your regex matches aren't enough - more states come 
in for example

if (match(str, regex("abc|def|as+b?") && BLUB || BLA ... )
{
     s1();
}else if (match(str, regex("za+|wd?|aaa")){
...

then your switches getting more and more unreadable - your will seperate 
bool algeb. into some helper variables - like this

bool special_active = match(str, regex("abc|def|as+b?") && BLUB || BLA;

if ( special_ative )
{
     s1();
}else if (...){
...

so is see a little help in trivial cases but it won't solve any big 
problem out there
May 12 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
 dennis luehring

----------------------------------------------------------------------
if (match(str, regex("abc|def|as+b?") && BLUB || BLA ... )
{
     s1();
}else if (match(str, regex("za+|wd?|aaa")){
...
----------------------------------------------------------------------

switch(str){
                     // regexp
 case "abc", "def", "as+b?":
   if( str == xxxx || str == yyyy && etc...){ // some other condition...
      s1();
   }
   break;

 case "za+", "wd?", "aaa":
   s2();
   break;

 default: s3();
 }

Denise, please note that I did not say it could not be done with if-else chain,
but switch makes some logical writing easier and code generation processing
easier.

Some of the valid reason:
1) Less key stroke
2) Easier code generator to implement ( switch case can be processed by awk like
script with marker like 'case' and 'break'.

Most of the time, by making the code easier for man to read it also makes
generations of code easier.


http://www.digitalmars.com/d/

D is a systems programming language. Its focus is on combining the power and
high
performance of C and C++ with the programmer >productivity< of >modern<
languages
like Ruby and Python. Special attention is given to the needs of quality
assurance, documentation, management, portability and reliability.
May 12 2011
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 12.05.2011 14:58, schrieb Matthew Ong:

 Denise, please note that I did not say it could not be done with if-else chain,


that is clear


 but switch makes some logical writing easier


in simple/trivial cases, and when i becomes more complex
you switch back to inner case ifs


 and code generation processing easier.


i don't see the point here - and i've written masses of codegens


 Some of the valid reason:
 1) Less key stroke
 2) Easier code generator to implement ( switch case can be processed by awk
like
 script with marker like 'case' and 'break'.


did you see the string mixin feature before?

http://www.digitalmars.com/d/2.0/mixin.html

no outer (parsing) generator needed anymore (with small exceptions) :)
May 12 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
== Quote from dennis luehring (dl.soluz gmx.net)'s article

 Am 12.05.2011 14:58, schrieb Matthew Ong:



 did you see the string mixin feature before?
 http://www.digitalmars.com/d/2.0/mixin.html
 no outer (parsing) generator needed anymore (with small exceptions) :)


I fail to see what is being addressed here in relation to switch.
What you have shown me is about Regexp and Mixin.
Is mixin related to code generations or switch or...?
Is there a way for you to show some sample code that demo what you wants to say?
May 12 2011
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 12.05.2011 15:57, schrieb Matthew Ong:

 == Quote from dennis luehring (dl.soluz gmx.net)'s article

  Am 12.05.2011 14:58, schrieb Matthew Ong:



  did you see the string mixin feature before?
  http://www.digitalmars.com/d/2.0/mixin.html
  no outer (parsing) generator needed anymore (with small exceptions) :)


 I fail to see what is being addressed here in relation to switch.
 What you have shown me is about Regexp and Mixin.
 Is mixin related to code generations or switch or...?
 Is there a way for you to show some sample code that demo what you wants to
say?



 I fail to see what is being addressed here in relation to switch.


realated to your awk-it-easier-for-codegenerators --> that are 
string-mixins for


 Is mixin related to code generations or switch or...?


code-generation


 Is there a way for you to show some sample code that demo what you 


wants to say?

i don't need to - your examples do show that your idea does not solve 
bad problems, or simple/medium ones very good - and the arguments about 
the code-generation isn't a big problem in D
May 12 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
Hi Dennis,

From what I can see u did not provide any clear answer and hence,
I would only discount all your threads as hostile to someone new to
D-Programming that is asking sincere and providing some clearly supportable
features. If those feature are as what u have rapidly
shot down. Then, may I ask, why the builder of bash and other similar
script level language supports.

From what I can see D is trying to bridge the gap of API level programming
language and Scripting Language like Ruby and others.

The point of success in any large scale and long term development
cycle in shown clearly in the industry is to make things easy and
approachable.

And not to take a Guru(ONLY I know best) approach?? Mind you, you
are not omnipotent.

I am not too sure if you work for digitalmars. But I hope not, because
that is what is being shown here.

http://www.digitalmars.com/d/
-----------------------------------------------------
Notice: We >welcome feedback< about the D compiler or language, but please be
explicit about any claims to intellectual property rights with a copyright or
patent notice if you have such for your contributions.
May 12 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
Note that it would in principle be possible to have a library-based solution
that
provides the functionality you want with the following syntax:

import rswitch; // I made that module name up.
...
mixin(rswitch(q{
switch(str){
  case "abc", "def", "as+b?":
    if( str == xxxx || str == yyyy && etc...)
       s1();
    }
    break;

  case "za+", "wd?", "aaa":
    s2();
    break;

   default: s3();
}
}));

AST macros will eventually make this look even prettier but I think that will
not
be too soon.

Timon




 Hi Dennis,

 From what I can see u did not provide any clear answer and hence,
 I would only discount all your threads as hostile to someone new to
 D-Programming that is asking sincere and providing some clearly supportable
 features. If those feature are as what u have rapidly
 shot down. Then, may I ask, why the builder of bash and other similar
 script level language supports.

 From what I can see D is trying to bridge the gap of API level programming
 language and Scripting Language like Ruby and others.

 The point of success in any large scale and long term development
 cycle in shown clearly in the industry is to make things easy and
 approachable.

 And not to take a Guru(ONLY I know best) approach?? Mind you, you
 are not omnipotent.

 I am not too sure if you work for digitalmars. But I hope not, because
 that is what is being shown here.

 http://www.digitalmars.com/d/
 -----------------------------------------------------
 Notice: We >welcome feedback< about the D compiler or language, but please be
 explicit about any claims to intellectual property rights with a copyright or
 patent notice if you have such for your contributions.
May 12 2011
prev sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 12.05.2011 16:33, schrieb Matthew Ong:

  From what I can see u did not provide any clear answer and hence,
 I would only discount all your threads as hostile to someone new to
 D-Programming that is asking sincere and providing some clearly supportable
 features. If those feature are as what u have rapidly
 shot down. Then, may I ask, why the builder of bash and other similar
 script level language supports.


sorry for that - but i do not got the feeling that you spend much time 
thinking about this "feature" - except "that would be cool"... but maybe 
its just the sounding


  From what I can see D is trying to bridge the gap of API level programming
 language and Scripting Language like Ruby and others.

 The point of success in any large scale and long term development
 cycle in shown clearly in the industry is to make things easy and
 approachable.

 And not to take a Guru(ONLY I know best) approach?? Mind you, you
 are not omnipotent.


yes im not, but try to think more deep about your ideas, especially when 
beeing in contact with an new language that short time


 I am not too sure if you work for digitalmars. But I hope not, because
 that is what is being shown here.


very few poeple (if im correct) working for digitalmars - most 
contributors a freely helping - and there a several big players around here
May 12 2011
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
Matthew Ong wrote:

 == Quote from dennis luehring (dl.soluz gmx.net)'s article

 Am 12.05.2011 14:58, schrieb Matthew Ong:



 did you see the string mixin feature before?
 http://www.digitalmars.com/d/2.0/mixin.html
 no outer (parsing) generator needed anymore (with small exceptions) :)


 I fail to see what is being addressed here in relation to switch.
 What you have shown me is about Regexp and Mixin.
 Is mixin related to code generations or switch or...?
 Is there a way for you to show some sample code that demo what you wants to
say?


I think he was referring to the fact that D's mixin and import allow you to
write
lightweight "parsers" for your own Domain Specific Languages.

mixin(strange_switch_supporting_DSL_to_D(import("filename")));

I do not really see the value added to D by such a construct either btw.
Its uses would be very rare while it would add some heavy complexity to the
compiler. Not to mention regex support would have to become built-in etc.

Timon
May 12 2011
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 12/05/2011 13:21, Matthew Ong wrote:

  dennis luehring


<snip>

 I do not think that this is syntactic sugar. Compare this 2 block of code.
Which
 is easier to read?


<snip>

Features to improve the readability of code are the very definition of
syntactic sugar. 
Indeed, Prolog programmers rely on syntactic sugar a lot.

Could you be thinking of syntactic saccharin?

Stewart.
May 17 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 17.05.2011 22:44, schrieb Stewart Gordon:

 On 12/05/2011 13:21, Matthew Ong wrote:

  dennis luehring


 <snip>

 I do not think that this is syntactic sugar. Compare this 2 block of
 code. Which
 is easier to read?


 <snip>
 
 Features to improve the readability of code are the very definition of
 syntactic sugar. Indeed, Prolog programmers rely on syntactic sugar a lot.
 
 Could you be thinking of syntactic saccharin?
 


Sweet syntax with a disgusting bitter aftertaste? ;)


 Stewart.
May 17 2011
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 17/05/2011 21:50, Daniel Gibson wrote:

 Am 17.05.2011 22:44, schrieb Stewart Gordon:


<snip>

 Could you be thinking of syntactic saccharin?


 Sweet syntax with a disgusting bitter aftertaste? ;)


I guess that would make sense.  But actually, syntactic saccharin is something
that may 
look at first like syntactic sugar but doesn't really help the programmer at
all. 
Something I think would count is the so-called complex string syntax in PHP.

Stewart.
May 26 2011
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 17/05/2011 21:44, Stewart Gordon wrote:
<snip>

 Features to improve the readability of code are the very definition of
syntactic sugar.
 Indeed, Prolog programmers rely on syntactic sugar a lot.


<snip>

Come to think of it, some of the everyday features of programming languages
generally are 
syntactic sugar.  For example:
- comments
- whitespace
- operator precedence/associativity rules
- comma-separated declarations
- with statements
- many of the logical operators found in C-like languages

Stewart.
May 26 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/12/11 6:13 AM, Matthew Ong wrote:

 Hi All,

 Anyway to include this cool feature of switch with D in the near future?

 switch(str){
                     // regexp
 case "abc", "def", "as+b?": s1(); break;

 case "za+", "wd?", "aaa": s2(); break;

 default: s3();
 }


This is a nice feature, but probably it won't be added to D.

Somebody new to a programming language often has a collection of nice 
artifacts from the other languages she might know. At first, they seem 
very worthwhile and of obvious benefit. Once the person continues using 
the language for a while, a sense develops for what is in the spirit of 
that language and what is less so. The opposition to this feature has 
been more or less rationalization of that intuition.


Thanks for joining,

Andrei
May 12 2011
parent Matthew Ong <ongbp yahoo.com> writes:
Hi,

The over all process perhaps is wrong,
I would use a more mature enviroment with huge sets or code sample to
build some commonly used routine for myself. And later export them
into various different language using process like this.

http://xes.sourceforge.net/

The library that I shown so far was in Java and I do have some plan


...
The more higher level an (API + Script like) language can go the better coding
and
providing ease of usage is key for success.

Just a process level idea, in the real world mission critical requirements has
more needs. Like Finance, Military and Telco.
May 12 2011
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-05-12 07:13:59 -0400, Matthew Ong <ongbp yahoo.com> said:


 Anyway to include this cool feature of switch with D in the near future?
 
 switch(str){
                    // regexp
 case "abc", "def", "as+b?": s1(); break;
 
 case "za+", "wd?", "aaa": s2(); break;
 
 default: s3();
 }


The idea is nice. But it breaks one interesting fundamental property of 
the switch statement: in a switch statement, each 'case' is mutually 
exclusive with every other so that the order of the 'case' labels has 
no importance when choosing which one to jump to. Try it: the compiler 
will generate a compile-time error if two cases attempt to match the 
same value. It also means that you can put 'default' in the middle of 
the 'switch' statement if you want and it won't prevent following cases 
from being matched:

	switch (str) {
		case "za+", "wd?", "aaa": s2(); break;
		default: s3(); break;
		case "abc", "def", "as+b?": s1(); break;
	}

How this is this exclusivity supposed to be enforceable with a regular 
expression (or other kinds of pattern matching) remains nebulous.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 12 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Matthew Ong:


 Anyway to include this cool feature of switch with D in the near future?


I think there are no plans in adding a switch as powerful as you ask.

The idea of adding pattern matching to D as in functional languages (as seen in
Haskell, OCaML or even Scala) was discussed, it's a nice feature if you also
have algebraic data types, but it will not be added to D2 and probably not even
to D3, despite D wants to be a bit functional too.

On the other hand there is an enhancement request about making switch a little
more powerful:
http://d.puremagic.com/issues/show_bug.cgi?id=596

D switch already supports switching on strings, so switching on arrays too
(like an array of ints) is probably not too much hard to add. And switching on
structs too will be quite useful (example: BigInts too become usable). Such
switch enhancements probably aren't for D2.

Bye,
bearophile
May 12 2011