[nem-bug] [Nemerle 0000827]: Weird case-sensitiveness in name binding in pattern matching

feedback at nemerle.org feedback at nemerle.org
Tue Jan 30 03:06:47 CET 2007


A NOTE has been added to this issue.
======================================================================
<http://nemerle.org/bugs/view.php?id=827> 
======================================================================
Reported By:                akhropov
Assigned To:                
======================================================================
Project:                    Nemerle
Issue ID:                   827
Category:                   Compiler (match compiler)
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
======================================================================
Date Submitted:             01-16-2007 23:29 CET
Last Modified:              01-30-2007 03:06 CET
======================================================================
Summary:                    Weird case-sensitiveness in name binding in pattern
matching
Description: 
def i = 5;
def j = 10;

def s = match((i,j)) {
    | (i1,j1) => $"i1 = $i1, j1 = $j1"   // this works
    //| (I1,J1) => $"I1 = $I1, J1 = $J1" /* and this doesn't 
                                            (compiler reckons them to be
type                        
                                             names for some reason)
                                         */
}

System.Console.WriteLine(s);
======================================================================

----------------------------------------------------------------------
 nazgul - 01-19-07 17:39 
----------------------------------------------------------------------
This is by design:

for variants you can specify:

variant {
  | Aa
  | Ab
  | C
}

and use it as:

match (x) {
  | Aa => ..
  | Ab =>..
  | C => ..
}

Now consider such match:

match (x) {
  | Aa => ..
  | Ac => ...
}

without the check you get into, last case would be interpreted as variable
name and match anything, which would be quite ugly bug. So we enforce some
convention to use uppercase for variant types and lowercase of variables
in match cases.

----------------------------------------------------------------------
 akhropov - 01-25-07 12:13 
----------------------------------------------------------------------
Well, this convention should be documented somewhere then.
Anyway, I think it isn't a so good idea because:

1) .NET CLS doesn't impose any restrictions on type names so classes that
begin with lowercase letters are absolutely legal. It's somewhat
inconsistent to use other specific rules.

2) Upper/lowercase should be language-independent (for example, it doesn't
work for Cyrillic names now). While this can be fixed there're languages
that don't have a notion of lower/uppercase (take Chinese or Japanese for
example).

3) I think 

| x => <use x as binded variable> may be confusing indeed. I'd rather
prohibit this for this purpose and use

| (x) => ... // smth like 1-tuple

or 

| _ as x => // this explicitly stresses with '_' that this is an 'anything
else' case.

----------------------------------------------------------------------
 nazgul - 01-26-07 19:11 
----------------------------------------------------------------------
> 1) .NET CLS doesn't impose any restrictions on type names so classes that
begin with lowercase letters are absolutely legal. It's somewhat
inconsistent to use other specific rules.

This is not an issue, since the check if necessary only for variants and
only Nemerle compiler can generate variants

> 2) Upper/lowercase should be language-independent (for example, it
doesn't work for Cyrillic names now). While this can be fixed there're
languages that don't have a notion of lower/uppercase (take Chinese or
Japanese for example).

Oh well, is it really that important? Of course the check could be
culture-specific, but this has a drawback that the same code which
compiles on one machine would fail on the other machine.

> 3) I think
>| x => <use x as binded variable> may be confusing indeed. I'd rather
prohibit >this for this purpose and use
>
>| (x) => ... // smth like 1-tuple

These are MUCH more breaking and inconvenient changes than forcing user to
use lowercase in variable names in matching. Moreover, user gets a clear
message what is going on. 

To some degree naming conventions are part of the language and here is the
place where we make it explicit.

----------------------------------------------------------------------
 pbludov - 01-30-07 03:06 
----------------------------------------------------------------------
I suggest to issue a warning in such case:

variant {
  | Aa
  | Ab
  | C
}

match (x) {
  | aa => .. // Warning: match pattern `aa' differ only in case with `Aa'
  | ab => .. // Warning: match pattern `ab' differ only in case with `Ab'
  | CC => .. // OK
  | cc => .. // Warning: match pattern `cc' differ only in case with `CC'

}

It is not important is Nemerle a case sensitive language or not, until it
becomes a semi-sensitive language.
Having a language that is somewhere case-sensitive, somewhere not is a
design bug, IMHO.

Issue History
Date Modified  Username       Field                    Change              
======================================================================
01-16-07 23:29 akhropov       New Issue                                    
01-19-07 17:39 nazgul         Note Added: 0001609                          
01-19-07 17:39 nazgul         Status                   new => feedback     
01-19-07 17:39 nazgul         Description Updated                          
01-25-07 12:13 akhropov       Note Added: 0001635                          
01-26-07 19:11 nazgul         Note Added: 0001644                          
01-30-07 03:06 pbludov        Note Added: 0001658                          
======================================================================




More information about the bugs mailing list