Walter Bright wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:43F53BE5.8020900@nospam.org...
> 
>> Using regexps in C needs a total change of paradigm. Regexps are
>> kind of "top down" things, wherease traditionally "peeking into
>> strings" is bottom-up programming.
>> 
>> You'd also have to learn regexps. The trivial things are trivial in
>>  C-style too, and the non-trivial stuff gets avoided because of the
>>  up-front investment. Folks rather do nested ifs and stuff.
>> 
>> Conversely, many interpreted languages make it inefficient to do
>> "peek" kind of programming, as compared to using regexps.
> 
> There are a lot of cool things you can do in script languages because
> they are interpreted, and one doesn't care about efficiency. Those
> things are simply incompatible with D. But I don't see any inherent
> advantages script languages should have in implementing regex.

Neither do I.

But the question was, how come regexps aren't _used_ as much as we'd expect.

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:43F58CDB.9090504@nospam.org...
> Walter Bright wrote:
>> There are a lot of cool things you can do in script languages because they are interpreted, and one doesn't care about efficiency. Those things are simply incompatible with D. But I don't see any inherent advantages script languages should have in implementing regex.
>
> Neither do I.
>
> But the question was, how come regexps aren't _used_ as much as we'd expect.

My answer is because they're inconvenient to use in C/C++.

"Oskar Linde" <olREM@OVEnada.kth.se> wrote in message news:dt41c8$2a9a$1@digitaldaemon.com...
> Walter Bright wrote:
>
>>
>> "Oskar Linde" <olREM@OVEnada.kth.se> wrote in message news:dt1ccm$2ssg$1@digitaldaemon.com...
>>> $.pre
>>> $.post
>>> $[0]
>>> $[n]
>>> (or $.match(n), but why not overload opIndex?)
>>
>> That was the original plan, but when _match is of type T*, the [ ] cannot be overloaded.
>
> So why does _match have to be a pointer?

I wanted it to work with both pointers to structs and to class references.

> Would something like this not work?

The problem with that is testing:

    _Match m;
    if (m)

doesn't work if _Match is a struct.

Walter Bright wrote:
> "Julio César Carrascal Urquijo" <jcesar@phreaker.net> wrote in message news:dt28a3$o2q$1@digitaldaemon.com...
>> Oskar Linde wrote:
>>> char[] cutHeadAndTail = myString[1 .. $.length-1];
>>> Image subImage = myImage[$.upperLeft .. $.middle];
>>> char[] contents = text[$.indexOf('{')+1 .. $.indexOf('}')];
>> This is a great idea. I like it.
> 
> There is one problem with it: every time an IfStatement is added to existing code, it will break all uses of $ in the ThenStatement:
> 
> ----- before --------
> if (foo())
>     $.bar = 3;
> ------ after ---------
> if (foo())
> {
>      if (abc())
>         $.bar = 3;    // uh-oh!
> }
> ----------------------
> 
> This is of course a trivial example, but consider if the $ appeared in a large block of code. 
> 

Coding guidelines would probably say that $ should be assigned to a named variable for all but the simplest blocks:
if (foo()) {
	auto myvar = $;
	...
}
The $ would be kind of elusive and only usable in its outermost scope. But the MatchExpression injected _match has the same problem. Consider the following hypothetical refactoring example:

const char[] two_argument_function_call = r"([_a-zA-Z][_0-9a-zA-Z]*)\(([^,\(\)]+),([^,\(\)]+)\)";

// Find function-calls
if (two_argument_function_call ~~ str) {
	// Swap the order of arguments for functions named array_*
	if ("array_(.+)" ~~ _match.match(1)) {
		// Need access results from outer _match.
	}
	...
}

And here is something the current MatchExpression behavior suffers from that a general scope variable would not:

if (a ~~ b) {
	if (c == d && e ~~ f) {
		do_something(_match.match(0)); // (*)
	}
}				

*) here e ~~ f is not injecting its result and _match refers to the result of a ~~ b

The apparent innocent change of removing the condition c == d from the if-statement will suddenly and silently have a side effect of injecting a shadowing _match variable and thus alter the argument to do_something().

Maybe this is a good time to consider Ben Hinkle's suggested declare-and-init operator := as a non-verbose way of naming sub-expressions.
http://www.digitalmars.com/d/archives/digitalmars/D/28198.html
(Also similar to Serg Kovrovs suggestion on the Semantic Scope Operator thread)

if (m := a ~~ b) {
  ...
  if (n := c ~~ m.match(0)) {
  ...
  }
}

/Oskar

In article <dt4nqs$2erg$1@digitaldaemon.com>, Oskar Linde says...
>
>Maybe this is a good time to consider Ben Hinkle's suggested
>declare-and-init operator := as a non-verbose way of naming
>sub-expressions.
>http://www.digitalmars.com/d/archives/digitalmars/D/28198.html
>(Also similar to Serg Kovrovs suggestion on the Semantic Scope Operator
>thread)
>
>if (m := a ~~ b) {
>   ...
>   if (n := c ~~ m.match(0)) {
>   ...
>   }
>}
>

Sort of like an auto 'auto' declaration?  I gather that the point is that the lvalue to the := expession is transparent to the context in which it is used (kind of inlining a variable creation and assignment)?

Also, how about using $.outer instead?

Link for "SSO" thread (with syntax examples at bottom of post): http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/33645


- Eric Anderton at yahoo

Regan Heath wrote:
> On Thu, 16 Feb 2006 16:36:48 -0800, Kris <fu@bar.com> wrote:
>> "Sean Kelly" <sean@f4.ca> wrote
>>> Kris wrote:
>>>> "Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote ...
>>>>> Currently, every type - including void - can be used as the type on an
>>>>> array element. What would be the consequences for generic programming
>>>>> if T -> T[] isn't guaranteed to succeed?
>>>>
>>>> Easy fix ~ change the bool alias to byte, instead of bit :-)
>>>
>>> I already use byte in some cases :-)  But it lacks the boolean value
>>> safety of bit, so I tend to litter my code with asserts just to be sure
>>> something didn't get screwed up... or simply make sure I'm only comparing
>>> to zero and not-zero.  Either way, it's more error prone than I'd like.
>>
>> Yes, you're right of course. Would be just great if Walter would add a true
>> *cough* bool *cough* type that doesn't try to pack itself when used with
>> arrays.
> 
> A true bool would make several people happy.. but once one existed people would then want:
> 
> class A {}
> A a = new a();
> if (a) //error not boolean result.
> 
> right? That would bother me.
> 
I favor a true bool, but would still like to keep the if(<int>) idiom.

>> Packed bits are great too, but for different reasons.
> 
> Indeed, I can think of several uses for packed bits. i.e.
>  - Using them as a bunch of flags, generally boolean on/off flags.
>  - Representing/disecting packed data, i.e. tcp headers.
>  - Assembling/converting data i.e. 8bit to 7bit characters for SMS messages.
> 
> all of these can be done with & | ^ etc but it would be nice, i.e. more readable, easier to write if we could index the data.
> 
> I've suggested this before but is it perhaps possible to allow us to perform array operations on the basic types: byte, short, int, long. For the same reason that bit[] does not work, these could not provide a full set of array functionality, but it could provide much that would be of use, I suspect.
> 
> Examples:
> 
> int flags;
> ....
> if (flags[5]) //check for flag
>     flag[5] = 1; //set flag
> 
> void foo(long header) {
>   int length = header[0..5]; //copy bits to lvalue.
> ....
> 
An interesting idea, but maybe, to avoid conflicts syntax conflicts, we should have:
  if (flags.bits[5])
    flags.bits[5] = 0;

(the name "bits" could maybe be other)


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

pragma wrote:
> In article <dt4nqs$2erg$1@digitaldaemon.com>, Oskar Linde says...
>> Maybe this is a good time to consider Ben Hinkle's suggested declare-and-init operator := as a non-verbose way of naming sub-expressions.
>> http://www.digitalmars.com/d/archives/digitalmars/D/28198.html
>> (Also similar to Serg Kovrovs suggestion on the Semantic Scope Operator thread)
>>
>> if (m := a ~~ b) {
>>   ...
>>   if (n := c ~~ m.match(0)) {
>>   ...
>>   }
>> }
>>
> 
> Sort of like an auto 'auto' declaration?  I gather that the point is that the
> lvalue to the := expession is transparent to the context in which it is used
> (kind of inlining a variable creation and assignment)?

Yes, exactly so. The scope of such variables declared in the operand of for example if-statements should probably be similar to the scope of variables declared in the init-part of a for-declaration.

> Also, how about using $.outer instead?

$.outer could collide with a member identifier. Maybe using the keyword super somehow... or append another $, like $$ for outer, $$$ for outer(outer). I don't think it's very necessary when you can do
auto outer = $; before starting the inner scope.
/Oskar

"Oskar Linde" <oskar.lindeREM@OVEgmail.com> wrote in message news:dt4nqs$2erg$1@digitaldaemon.com...
> The apparent innocent change of removing the condition c == d from the if-statement will suddenly and silently have a side effect of injecting a shadowing _match variable and thus alter the argument to do_something().

Yes, that's a problem.

> Maybe this is a good time to consider Ben Hinkle's suggested
> declare-and-init operator := as a non-verbose way of naming
> sub-expressions.
> http://www.digitalmars.com/d/archives/digitalmars/D/28198.html
> (Also similar to Serg Kovrovs suggestion on the Semantic Scope Operator
> thread)
>
> if (m := a ~~ b) {
>   ...
>   if (n := c ~~ m.match(0)) {
>   ...
>   }
> }

It's a workable proposal. But it overlaps the functionality of 'auto' declarations a bit much. And:

    if (auto m = a ~~ b)

might be a little wordy? Perhaps:

    if (m; a ~~ b)

sort of along the lines of foreach?

Walter Bright skrev:
> "Oskar Linde" <oskar.lindeREM@OVEgmail.com> wrote in message news:dt4nqs$2erg$1@digitaldaemon.com...
> 
>>The apparent innocent change of removing the condition c == d from the if-statement will suddenly and silently have a side effect of injecting a shadowing _match variable and thus alter the argument to do_something().
> 
> 
> Yes, that's a problem.
> 
> 
>>Maybe this is a good time to consider Ben Hinkle's suggested declare-and-init operator := as a non-verbose way of naming sub-expressions.
>>http://www.digitalmars.com/d/archives/digitalmars/D/28198.html
>>(Also similar to Serg Kovrovs suggestion on the Semantic Scope Operator thread)
>>
>>if (m := a ~~ b) {
>>  ...
>>  if (n := c ~~ m.match(0)) {
>>  ...
>>  }
>>}
> 
> 
> It's a workable proposal. But it overlaps the functionality of 'auto' declarations a bit much. And:
> 
>     if (auto m = a ~~ b)
> 
> might be a little wordy? Perhaps:
> 
>     if (m; a ~~ b)
> 
> sort of along the lines of foreach? 
> 
> 
Yes! This one I like.

I have shuddred allot while reading this thread, I do not like too much magic happening in my code. This one is neat and simple, consistent with existing syntax. And most importantly; makes it quite hard to write incorrect code.

// Fredrik Olsson

Walter Bright wrote:
> "Oskar Linde" <oskar.lindeREM@OVEgmail.com> wrote in message news:dt4nqs$2erg$1@digitaldaemon.com...
>> The apparent innocent change of removing the condition c == d from the if-statement will suddenly and silently have a side effect of injecting a shadowing _match variable and thus alter the argument to do_something().
> 
> Yes, that's a problem.
> 
>> Maybe this is a good time to consider Ben Hinkle's suggested declare-and-init operator := as a non-verbose way of naming sub-expressions.
>> http://www.digitalmars.com/d/archives/digitalmars/D/28198.html
>> (Also similar to Serg Kovrovs suggestion on the Semantic Scope Operator thread)
>>
>> if (m := a ~~ b) {
>>   ...
>>   if (n := c ~~ m.match(0)) {
>>   ...
>>   }
>> }
> 
> It's a workable proposal. But it overlaps the functionality of 'auto' declarations a bit much. And:
> 
>     if (auto m = a ~~ b)
> 
> might be a little wordy? Perhaps:
> 
>     if (m; a ~~ b)
> 
> sort of along the lines of foreach?

I like it.  Assuming this were implemented, would it affect all conditional expressions except foreach?


Sean