[nem-bug] [Nemerle 0000827]: Weird case-sensitiveness in name
binding in pattern matching
feedback at nemerle.org
feedback at nemerle.org
Fri Jan 26 19:11:12 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-26-2007 19:11 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.
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
======================================================================
More information about the bugs
mailing list