Changes between Version 3 and Version 4 of SQLLikeComprehensions


Ignore:
Timestamp:
Oct 28, 2007 8:15:46 PM (6 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{{{