I’m posting a shorter and less dense solution to your problem below. Hope that helps


import Control.Monad
import System.Environment

main = getArgs >>= mapM (print . maybe False null . parse)


public class SimpleBraceParser {

  private int index = 0;
  private String s;

  public SimpleBraceParser(String s) { this.s = s; }

  private void skip(char c) {
    ++index;
  }

  private char currentChar() {
    if (index < s.length()) return s.charAt(index);
    else return ''; // Evil "sentinel" value
  }

  private void eat(char c) {
    if (currentChar() == c) {
      ++index;
      return;
    }
    throw new RuntimeException("parse error at " + index + ", expecting '" + c + "'");
  }

  public void parseRoundBrace() {
    skip('(');
    parseExpr();
    eat(')');
  }

  public void parseSquareBracket() {
    skip('[');
    parseExpr();
    eat(']');
  }

  public boolean parseExpr() {
    if (currentChar() == '(') {
      parseRoundBrace();
      return true;
    } else if (currentChar() == '[') {
      parseSquareBracket();
      return true;
    } else return false;
  }

  public void parseExprs() {
    while (parseExpr()) {
    }
  }

  public void parse() {
    parseExprs();
    if (currentChar() != '')
      throw new RuntimeException("not terminated correctly at " + index);
  }

  static boolean reportErrors = false;

  public static void main(String[] args) {
    for (String arg : args) {
      SimpleBraceParser p = new SimpleBraceParser(arg);
      try {
        p.parse();
        System.out.println("true");
      } catch (Exception e) {
        if (reportErrors) e.printStackTrace(System.err);
        System.out.println("false");
      }
    }
  }

}

Yep, it’s pretty long! I like top-down parsers as they are pretty intuitive. I’d use Antlr for any more serious parser work.

I really like the look at the Haskell version with Parsec. I tested your Haskell, Scala and Java versions along with my Java version and the Parsec version (amongst others). Your Haskell version and Parsec are very fast - Parsec is faster :). I only used /usr/bin/time to test so the JVM startup time could have hampered the Java solutions. My recursive Java version and your Scala version require stack-size increases (on my large inputs).

With the Scala version performance extremely poorly on large inputs. Pretty sure it doesn’t matter if the inputs are heavily nested or not. Maybe Scala isn’t the best language for functional style code. Are there any ways to improve the performance and stay functional?

def parse(s) { def t = s.replace(”[]“, “”).replace(”()”, “”); t == s ? t : parse(t) }
args.each { println parse(it) == “” }

A little less imperative:

brackets = ["[]“, “()”]
def parse2(s) { def t = brackets.inject(s){ a, b -> a.replace(b,”") }; t == s ? t : parse2(t) }

Anyway, thanks again for this nice setting. Could you be a bit more clear about the composability issues you were aiming at ?

Bracket configuration. Single point of configuration of valid opening and closing brackets in the initializer of char matching_brackets[]. Public interface:

is_opening_bracket(char c)
get_matching_closing_bracket(char c))

The parsing module. Public interface:

check(const char* str)

The main program. Public interface:

main(int argc, const char* argv[])

#include <stdio.h>
#include <assert.h>

/* Section 1: configuration of brackets and accessors to it. */

/* Mapping from opening brackets to closing brackets. */
char matching_brackets[256] = {
    ['('] = ')',
    ['['] = ']'
};

int is_opening_bracket(char c)
{
    return matching_brackets[(unsigned char) c] != '';
}

char get_matching_closing_bracket(char c)
{
    assert(is_opening_bracket(c));
    return matching_brackets[(unsigned char) c];
}

/* Section 2: the parsing function itself. */

/* Parse a sequence of valid start/end brackets followed by
 * 'expected'.*/
const char* parse(char expected, const char* str)
{
    return
            /* In case of NULL input, return NULL. */
            (str == NULL) ? NULL
            /* In case of succeeded match, return the rest of the string;
             * as a special case, if 'expected' is 0, return pointer to
             * it to signal success. */
        :   (*str == expected) ? *str == 0 ? str : str + 1
            /* In case of opening bracket, parse until its matching
             * closing bracket and then continue from there */
        :   is_opening_bracket(*str) ?
            parse(expected, parse(get_matching_closing_bracket(*str), str + 1))
            /* In case of anything else, return NULL */
        :   NULL;
}

/* Is str a valid sequence of paired brackets? */
int check(const char* str)
{
    const char* result = parse(0, str);
    return (result != 0 && *result == 0);
}

/* Section 3: the main program. */

/* Walk through all parameters and show parse results. */
int main(int argc, const char* argv[])
{
    while (++argv, --argc) {
        printf(check(*argv) ? "true\n" : "false\n");
    }
    return 0;
}

Unlike some might say, it would seem that brevity is occasionally the enemy of maintainability. Or is it just a daydream by us Blub programmers?

A C solution:

#include <stdio.h>

char matching_parens[256] = { ['('] = ')', ['['] = ']' };

const unsigned char* look_for(unsigned char expected, const unsigned char* str)
{
    return (str == 0) ? 0
        :  (*str == expected) ? *str == 0 ? str : str + 1
        :  (matching_parens[*str]) ?
           look_for(expected, look_for(matching_parens[*str], str + 1))
        :  0;
}

int main(int argc, const char* argv[]) {
    while (++argv, --argc) {
        const unsigned char* result = look_for(0, *((unsigned char**) argv));
        printf((result != 0 && *result == 0) ? "true\n" : "false\n");
    }
    return 0;
}

public class BracketParser {

    public static void main(String[] args) {
        for(String arg : args) {
            System.out.println(parse(arg));
        }
    }

    public static boolean parse(String arg) {
       while(arg.length() !=0 && ( arg.contains("()") || arg.contains("[]"))) {
            arg = arg.replace("[]", "").replace("()", "");
        }
        return arg.length() == 0;
    }
}

bool Parse<A>(
IEnumerable<A> inputSequence,
IEnumerable<Pair<Predicate<A>, Predicate<A>> openClosePredicates)

First pass, a little more flexible, would be to have a function which accepts a set of brace pairs, with a signature like;

[string]->string->bool.

Or in C#;

bool Parse(string input, IEnumerable bracePairs)

which you partially-apply like;

var tokens = new [] { “[]“, “{}” };
Predicate bracketParser = args => Parse(args, tokens);

so you can pass your list of open-close characters in. That would extend it to use any number of bracket pairs.

More generally, though, why not extract the string data type entirely? The underlying idea, I think, is that we want to pair open and close operations on a sequence. So paren-matching is connected to these predicates (C#);

char => char == ‘(’
char => char == ‘)’

But who cares about characters specifically? We can get to a general matcher, which will match paired open/close predicates in any sequence. I think the haskell type looks like [(a->bool, a->bool)]->a->bool. (That first type should be ‘list of pairs of predicates of a’. In C#

bool Parse(
IEnumerable inputSequence,
IEnumerable<Pair<Predicate, Predicate> openClosePredicates)

Hmm…