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:

 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.


 this does limit such possibilities as optimised regexp switches.

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

just need literals for associative arrays.
 On the other hand my experience shows me some other things are better as

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

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

 (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?

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

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

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:

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:

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.

-- 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.


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.

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.

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 

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

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

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

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

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:

 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.

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
to port them either to D or Go or Both and even C#

...
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 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