Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I like it because you can practically use this to define a grammar for parsing a programming language, because:

1. Each data type can inline express its own value constraints (not just type constraints, but rather value constraints) which is key to source code parsing

2. With subclasssing you can combine data types into higher level objects that inherit all of the lower level value constraints. This is similar to how a recursive lexer drills down from a high level statement into the different parts of each statement.

3. The data type value constraints support sequences, alternatives, and unions, most of what a lexer needs to parse a language based on a grammar spec

With these ingredients you can actually parse code, and thereby write a code interpreter (or parser at least). You begin with a grammar rule (a high level data type) that defines a statement, and a statement is defined as a list of alternatives forms of a statement, and each statement form is defined as a sequence of keywords and supported value types, and so on down the language primitives.

... but I'm not sure if supports recursion, and thereby recursive descent parsing. Can you say something like "Sum = [Sum, Operand, Sum]" If not then you're limited to immediate values only and no nested expressions.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: