Walter Bright wrote:
> "pragma" <pragma_member@pathlink.com> wrote in message news:dt0mfk$29qc$1@digitaldaemon.com...
> 
>>Also, am I to assume that we'll get an "opProcess" operator overload to use on
>>our classes?
> 
> 
> Yes, opMatch. Already done!
> 

Walter!! You are really crazy! (In a really really good way)

I just tried this for fun and it works:

<code>

import std.stdio;

class ArrayBeginsWith0and1
{
  static bool opMatch(int[] nums)
  {
    if(nums.length < 2)return false;
    if(nums[0] == 0 && nums[1] == 1) return true;
    else return false;
  }
}

void main()
{
  static int[] somearray1 = [0,1,2];
  static int[] somearray2 = [2,1,2];

  writefln(ArrayBeginsWith0and1 ~~ somearray1); //prints true
  writefln(ArrayBeginsWith0and1 ~~ somearray2); //prints false
}

</code>

I hope this isn't a bug that this works?

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.

pragma wrote:
> In article <dt1eje$2uvu$2@digitaldaemon.com>, Walter Bright says...
> 
>>
>>"Oskar Linde" <olREM@OVEnada.kth.se> wrote in message news:dt1aif$2qpd$1@digitaldaemon.com...
>>
>>>Have you considered making this more general? I.e. for all if statements,
>>>inject a variable that takes the value of the entire condition expression.
>>>(Using _result as a placeholder for such an identifier.)
>>>
>>>if ("..." ~~ "...) {
>>> _result.match(0);
>>>}
>>>
>>>if (myFunc()) {
>>> _result.whatever();
>>>}
>>>
>>>Why should this behavior be reserved for opMatch() only? Isn't this a very
>>>common coding pattern that could also become less verbose by this:
>>>
>>>SomeType result;
>>>if ( (result = getSomething())) {
>>>       doSomethingWith(result);
>>>}
>>>
>>>(becoming:
>>>
>>>if (getSomething()) {
>>>       doSomethingWith(_result);
>>>}
>>>
>>>)
>>>
>>>One suggestion would be to call _result $. Giving $ the semantics of a
>>>"scope injected value". This would go hand in hand with an earlier
>>>suggestion of changing the $ for index operations too:
>>>
>>>Assume [] introduces a new scope, then a $ within [] would refer to whatever
>>>is being indexed.
>>>
>>>char[] cutHeadAndTail = myString[1 .. $.length-1];
>>>Image subImage = myImage[$.upperLeft .. $.middle];
>>>char[] contents = text[$.indexOf('{')+1 .. $.indexOf('}')];
>>
>>I never thought of that. It's an intriguing idea. 
>>
> 
> 
> Something along these lines would *most certainly* get my vote!
> 
> - Eric Anderton at yahoo

Yes ~ mine too

Walter Bright wrote:
> "Kris" <fu@bar.com> wrote in message news:dt0q7n$2cuo$1@digitaldaemon.com...
>> There seem to be multiple issues here. The first one, which you ask about, is related to the syntax. At first blush, the ~~ looks like an approximate approximation, and then making D look like a malformed Perl is surely a mistake.
> 
> If you've got a better idea for tokens ~~ and !~ ?

I'm half inclined to suggest -> for ~~, though there doesn't seem to be an obvious corresponding 'not' version.


Sean

kris wrote:
> pragma wrote:
>> In article <dt1eje$2uvu$2@digitaldaemon.com>, Walter Bright says...
>>
>>>
>>> "Oskar Linde" <olREM@OVEnada.kth.se> wrote in message news:dt1aif$2qpd$1@digitaldaemon.com...
>>>>
>>>> One suggestion would be to call _result $. Giving $ the semantics of a
>>>> "scope injected value". This would go hand in hand with an earlier
>>>> suggestion of changing the $ for index operations too:
>>>>
>>>> Assume [] introduces a new scope, then a $ within [] would refer to whatever
>>>> is being indexed.
>>>>
>>>> char[] cutHeadAndTail = myString[1 .. $.length-1];
>>>> Image subImage = myImage[$.upperLeft .. $.middle];
>>>> char[] contents = text[$.indexOf('{')+1 .. $.indexOf('}')];
>>>
>>> I never thought of that. It's an intriguing idea.
>>
>>
>> Something along these lines would *most certainly* get my vote!
> 
> Yes ~ mine too

Mine too.


Sean

Sweet jesus ... the horror.




"Walter Bright" <newshound@digitalmars.com> wrote in message news:dt088e$1svm$2@digitaldaemon.com...
> D dramatically improves the convenience of string handling over C++. But while I think using the library std.regexp is straightforward, obviously
it
> just isn't gaining traction. People like the shortcut approaches Ruby and Perl use for regular expressions, hence the new D match-expression
support.
>
> So, now we have:
>
>     if (regular_expression ~~ string)
>     {
>             _match.pre
>             _match.post
>             _match.match(n)
>     }
>
> Should we do some aliases:
>
>     $` => _match.pre
>     $' => _match.post
>     $& => _match.match(0)
>     $n => _match.match(n)
>
> ? Syntactic sugar is often a good idea, but at what point do they become cyclamates and cause cancer in laboratory animals? Will these $ tokens render D more accessible, but perhaps too unreadable?
>
>

John Demme says...
>
>Walter Bright wrote:
>> 
>> Should we do some aliases:
>> 
>>     $` => _match.pre
>>     $' => _match.post
>>     $& => _match.match(0)
>>     $n => _match.match(n)
>> 
>> ? Syntactic sugar is often a good idea, but at what point do they become cyclamates and cause cancer in laboratory animals? Will these $ tokens render D more accessible, but perhaps too unreadable?
>
>Oh Bob no... Don't turn D into Perl.  I like the $ for short cuts and such, but please no random symbols.  I like $match.pre and $length, ect... but $& and $` don't mean anything to me!

I agree.  Perl is perl, D is D.

1

Walter Bright says...
>
>
>"John Demme" <me@teqdruid.com> wrote in message news:dt0fvp$23bj$1@digitaldaemon.com...
>> Oh Bob no... Don't turn D into Perl.  I like the $ for short cuts and
>> such,
>> but please no random symbols.  I like $match.pre and $length, ect... but
>> $&
>> and $` don't mean anything to me!
>
><g>. I considered setting this up as a vote:
>
>Vote for 1:
>
>(1) If I wanted to write ugly programs I'd use Perl, not D.
>
>(2) Cool! I can now dump my Perl scripts and use D!
>
>

Sean Kelly wrote:
> kris wrote:
>> pragma wrote:
>>> In article <dt1eje$2uvu$2@digitaldaemon.com>, Walter Bright says...
>>>
>>>>
>>>> "Oskar Linde" <olREM@OVEnada.kth.se> wrote in message news:dt1aif$2qpd$1@digitaldaemon.com...
>>>>>
>>>>> One suggestion would be to call _result $. Giving $ the semantics of a
>>>>> "scope injected value". This would go hand in hand with an earlier
>>>>> suggestion of changing the $ for index operations too:
>>>>>
>>>>> Assume [] introduces a new scope, then a $ within [] would refer to whatever
>>>>> is being indexed.
>>>>>
>>>>> char[] cutHeadAndTail = myString[1 .. $.length-1];
>>>>> Image subImage = myImage[$.upperLeft .. $.middle];
>>>>> char[] contents = text[$.indexOf('{')+1 .. $.indexOf('}')];
>>>>
>>>> I never thought of that. It's an intriguing idea.
>>>
>>>
>>> Something along these lines would *most certainly* get my vote!
>>
>> Yes ~ mine too
> 
> Mine too.

Hold on.  Walter, can you explain this injection business a bit?  For example, the effect here seems clear:

if( "x" ~~ "y" ) {
    _match.blah;
}

But what about this:

if( "x" ~~ "y" && "y" ~~ "z" ) {
    _match.blah;
}

And this:

if( "x" ~~ "y" || "y" ~~ "z" ) {
    _match.blah;
}

Does _match represent the result of the last match sub-expression evaluated?  And is there any way to know which expression succeeded? Does the fact that the injected value is a _Match* mean that I might potentially have an array of objects I could iterate through?  And finally, could you clarify the spec in this regard?

Also, with respect to the above proposal, how might this work:

int numStudents();
float avgGrade();

if( numStudents() < 10 || avgGrade() > 50.0 ) {

}

While the result of each subexression is actually boolean (just as in the match expression above), the values we'd be interested in are the integer and float.  But in the above example, the float might not be evaluated at all.  I'd merely like to voice this as a qualifier to my initial support of this idea above :-)


Sean

Sean Kelly wrote:

> Hold on.  Walter, can you explain this injection business a bit?  For example, the effect here seems clear:
> 
> if( "x" ~~ "y" ) {
>      _match.blah;
> }
> 
> But what about this:
> 
> if( "x" ~~ "y" && "y" ~~ "z" ) {
>      _match.blah;
> }
> 
> And this:
> 
> if( "x" ~~ "y" || "y" ~~ "z" ) {
>      _match.blah;
> }

Those are AndAndExpression and OrOrExpression and will not inject anything. Only a pure if(MatchExpression) injects anything.

> Also, with respect to the above proposal, how might this work:
> 
> int numStudents();
> float avgGrade();
> 
> if( numStudents() < 10 || avgGrade() > 50.0 ) {
> 
> }

In this case, $ would always refer to the value of (numStudents() < 10 ||
avgGrade() > 50.0), which is bool and must always be true. (It would be
interesting to change the || expression into returning the left value if it
is nonzero and the right value otherwise, without converting anything to
bool, but I'm not fully sure what implications that would have...)

> While the result of each subexression is actually boolean (just as in the match expression above), the values we'd be interested in are the integer and float.  But in the above example, the float might not be evaluated at all.  I'd merely like to voice this as a qualifier to my initial support of this idea above :-)

This is probably impossible. How would the compiler know what subexpressions are interesting and how would those be referred to?

/Oskar