C# FEATURE SUGGESTION: Create parse (string) statement and parse functions for easier to read/follow parsing

[amitchneck]

The parse statement would take a string and run it sequentially through a series of parse functions that would remove characters from the head of the string. If the last parse function left characters in the string or the string started out or became null, the parse statement would throw an exception. The parse functions would be line-by-line within the parse statement. To create a conditional branch (for instance the next character could be '+' or '-') you could use the +++ operator. To conditionally branch between multiple parse functions you could group parse functions with braces { }. The parse statement would accept pattern matching using the when clause to specify an additional condition to accept parsed value. For conditional branches, the parse statement would try to parse the first branch. If this succeeded, then the parse statement would skip the other branches. If this failed, then the parse statement would try the next branch. Once the last branch fails, the parse statement would throw an exception.

Parse functions would be functions with the parse keyword that can only be called using the parse statement. Parse functions would have access to a string value (as if it were a class variable for which the function is part of that class) named parsestring that, upon entry to the function, would never be null. Instead of throwing an exception, when a parse function encounters an issue with the given string, they would return after setting parsestring to null. As a parse function parses the string, they would remove characters from it. The parse statement takes a string value, passes this value to the first parse function, then passes the resultant string from the first parse function to the next parse function, and so on. Note, parse functions within a conditional branch start with the resultant string value from the last parse function before the first branch of the conditional branch. The first parse function after a conditional branch gets the resultant sting value from the first successful branch. When calling a parse function that doesn't have any input parameters from a parse statement you could leave out the trailing () characters.

For example, to parse an integer you could create the following function using a parse statement

int ParseInteger(string s)
{
  bool isNegative = false;
  int value;

  // this parser enables a string of digits to be preceded by -, + or nothing to be parsed as an integer
  parse (s)
  {
    {
      GetChar => c when c == '-'
      Assign<bool>(true) => isNegative
    }
    +++
    GetChar => c when c == '+'
    +++
    NoOp
    
    GetInteger => value
  }

  if (isNegative)
    return -value;
  else
    return value;
}

This would use the following parse functions

parse char GetChar() // this function extracts the head character from the string
{
  if (parsestring == "")
  {
    // no characters to read!
    // no need to test for null condition here as parsestring cannot start null
    parsestring = null;
    return; // no need to return value as parsestring is null
  }
  else
  {
    char c = parsestring[0];
    parsestring = parsestring.Remove(0, 1);
    return c;
  }
}

parse T Assign<T>(T value) => value; // this function enables general assignment of values within parse statement

parse void NoOp() { } // this function does nothing; primarily used as final conditional branch for optional condition

parse int GetInteger()
{
  if (parsestring == "" || !char.IsDigit(parsestring[0]))
  {
    // first character is not a digit
    parsestring = null;
  }
  else
  {
    int v = 0;
    while (parsestring != "" && char.IsDigit(parsestring[0]))
    {
      v = v * 10 + (int)parsestring[0] - 48;
      parsestring = parsestring.Remove(0, 1);
    }
    return v;
  }
}

Other useful parse functions

parse char PeekChar() // this function peeks at the head character from the string
{
  if (parsestring == "")
  {
    // no characters to peek!
    parsestring = null;
  }
  else
  {
    return parsestring[0];
  }
}

parse string Return() // this function returns remaining characters to be parsed to enable partial parse statements
{
  string s = parsestring;
  parsestring = "";
  return s;
}

[franchyd]

Nothing you are doing here appears to need a new keyword.

[mburbea]

I find this probably more confusing than anything else.
What's particularly different from say::

internal static (char head, string remainder) PeekChar(this string parsestring){
      var operatingOnEmpty = string.IsNullOrEmpty(parsestring);
      var head = operatingOnEmpty ?  "" : parsestring[0];
      var remainder = operatingOnEmpty ? "" : parsestring.Substring(1);
      return (head, remainder);
}

No strange rule about setting a variable to null to prevent continued execution. If you want you could build a library where you passed parsing rules as delegates and they would consume the chunk of the string they want.

But if you're going down that road, why not use an abstraction like Stream which captures an object that you want to track how far you've visited?

[HaloFour]

Sounds very much like something better suited for a library or function.

[svick]

I don't think special syntax for parsing belongs in a general purpose language like C#. Parsing belongs in a DSL (like ANTLR) or a library (like Sprache), because it is a domain-specific concept and because no single parsing approach will satisfy everybody (or even most people).

And even if that wasn't the case, I find this proposal too verbose and hard to understand. For example, using Sprache, the same example would be written as (keep in mind that I don't actually know that library, so there might be even better ways of achieving this):

from signChar in Parse.Chars('+', '-').Optional()
let isNegative = signChar.GetOrDefault() == '-'
from number in parseNumber
select isNegative ? -number : number

This is somewhat dense, but it's much shorter than what you're proposing and I'd say it's also easier to understand (even though you have to learn what is the relationship between LINQ and parsing).

And a language feature that is worse than what you can achieve with a library is not going to be added to the language.