Changes between Version 3 and Version 4 of SQLLikeComprehensions


Ignore:
Timestamp:
Oct 28, 2007 8:15:46 PM (8 years ago)
Author:
guest
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SQLLikeComprehensions

    v3 v4  
    3838
    3939When the parser reaches the bracket after "e" it is valid to either reduce "(i, e)" to a pair of qualifiers (i.e. i and e are treated as guard expressions), OR to reduce it to the tuple expression (i, e) which will be later converted to a pattern. There are a number of alternative ways we could solve this:
    40 * Disallow bracketing of qualifiers altogether!
    41  * This keeps the concrete syntax simple and should cover all common use cases
    42  * It does reduce the composability of the qualifier syntax rather drastically however
    43 * Keep bracketing in this manner but use type information to resolve the ambiguity
    44  * I will need to change the parser to consider qualifiers as expressions so that we can parse without any reduce/reduce conflicts
    45  * We can then always use type information to determine which reading is correct, because guards are always boolean, and so can be distinguished from tuples as required
    46  * Might have negative implications on the readability of some error messages :(
    47  * If the parser finds it hard to understand this syntax, you can argue that any human reader would too and hence we should look for something less ambiguous
    48 * Introduce new syntax to allow this idiom to be expressed unambiguously. Some examples of what we could use are below:
     40
     41 * Disallow bracketing of qualifiers altogether!
     42  * This keeps the concrete syntax simple and should cover all common use cases
     43  * It does reduce the composability of the qualifier syntax rather drastically however
     44 * Keep bracketing in this manner but use type information to resolve the ambiguity
     45  * I will need to change the parser to consider qualifiers as expressions so that we can parse without any reduce/reduce conflicts
     46  * We can then always use type information to determine which reading is correct, because guards are always boolean, and so can be distinguished from tuples as required
     47  * Might have negative implications on the readability of some error messages :(
     48  * If the parser finds it hard to understand this syntax, you can argue that any human reader would too and hence we should look for something less ambiguous
     49 * Introduce new syntax to allow this idiom to be expressed unambiguously. Some examples of what we could use are below:
    4950
    5051{{{