Given that Bernard Stepien’s presentation was given at a TTCN conference, it is quite natural that it aims to highlight benefits of TTCN. The circles are small, and he’s more or less a semi-regular presenter there. It is sad that the presentation is so clearly constructed purely for the purpose of making TTCN-3 look good, without any real attempt at a sound academic-quality comparison. Or maybe its just incompetence.

It is good to try & understand the differences though, so this kind of comparisons serve a purpose regardless

But getting into categorical argument about special-purpose testing language vs. using a general-purpose language for testing would be just plain silly. It all depends on purpose, context and requirements. For example, it would be silly to use TTCN-3 for direct testing of Python programs, but I would rather pick TTCN-3 for low-level telecommunications protocol conformance and interoperability testing any day. The testing-specific features built right into TTCN-3 are particularly useful for such purposes and contexts, and while they could be replicated in Python, the implementations would always be less elegant.

I will definitely update my implementation of univset based on this. Coincidentally I’ve just revised Langscape’s lexer and included set literals as well as pattern such as complement pattern ~{} expressing the same as the regexp dot. The inclusion of the __invert__ method matches the semantics perfectly. The algebraic equations look so nice that I could even imagine that some people on python.ideas find this cute and univset would be a great addition to the Python core.

if type(other) == univset:  return other._diff

Then you can take complements more generally:

NOT = univset()
assert NOT - (NOT-A) == A
assert NOT - (NOT - (NOT-A)) == NOT-A

And by adding an inverse method to both set and univset, you can express complementation quite nicely:

assert ~A == NOT-A
assert ~A & ~B == ~(A | B)
assert ~A | B == ~(A - B)
assert ~~A == A
assert ~~~A == ~A

I.E.:

class univset(object):
    def __invert__(self):
        return self._diff

class Set(set):
    def __invert__(self):
        U = univset()
        return U - self

Of course be sure to replace all set constructors with Set().

You might be correct about Earley parsers. I don’t know.

It will take a little time for me to figure out which concepts match Trails algorithms and which do not. For example Trail does some lookahead analysis in cases when rule expansion is cancelled. So it is already the essential fall-back mechanism, not backtracking. However I detected a bug in the parser implementation with respect to lookahead recently and haven’t had the time yet to analyse if it is fundamental or shallow. Anyway, it is an interesting paper, at least for me.

Scanning a string while maintaining the full set of reachable NFA states is just scanning a lazily determinized FSA – and it may make sense compared to backtracking, although it may take more space.

http://www.antlr.org/papers/LL-star-PLDI11.pdf

Regards, Terence

PyPgen doesn’t seperate a tokenization from a parsing phase. Instead the parser works lazily and reads the next token from the tokenizer which can produce it from a string on demand. One could do the tokenization in advance though and pass in a list of token wrapped into a handler with the necessary interface. Then it will be possible to compare the parser components speed-wise. Comparing the tokenizer used by Trail and tokenizer.py is not particularly fair, because the essential string matching by tokenizer.py is done using Pythons re module. So one would compare a pure Python solution against a C implementation – with a predicatble result.