List-type syntax constructors not properly checked

[GoogleCodeExporter]

Compile this file:

<http://svn.berlios.de/svnroot/repos/al4nin/trunk/found-bugs/issue16-Cat.omg>

----------------------------------------------------
I would expect that either the

"deriving List(rl)" declaration
a) gets rejected, or
b) the printing (and parsing) of Snoclist-like syntax gets supported:

prompt> revThrist RevNil [Dup, Print]l
[Dup, Print]rl

with this pattern schema:

[prefix; ..., penultimate, ultimate]rl

----------------------------------------------------
But I get:

prompt> revThrist RevNil [Dup, Print]l
[[[]rlDupPrint : forall a (b:Prod *0).RevThrist Cat [a; b]sh [a; b]sh

looks like major confusion :-)

Original issue reported on code.google.com by ggr...@gmail.com on 7 Jul 2007 at 2:19

[GoogleCodeExporter]

the corrected URL is
<http://svn.berlios.de/svnroot/repos/al4nin/trunk/found-bugs/issue17-Cat.omg>

Original comment by ggr...@gmail.com on 12 Jul 2007 at 12:55

[GoogleCodeExporter]

this is probably an issue with snoc-records too.

depending on the recursive occurrence of the type we
have a different parsing/showing:

{rest; c, b, a}x -----> Snoc-Record

Original comment by ggr...@gmail.com on 11 Dec 2007 at 4:46

[GoogleCodeExporter]

as of r393 the left-associative list syntax is implemented:

http://code.google.com/p/omega/source/browse/trunk/tests/LeftList.prg

Original comment by ggr...@gmail.com on 6 Dec 2010 at 10:45

[GoogleCodeExporter]

as of r419 the unit and item syntax extensions are available:

... deriving syntax Unit(Unit) Item(Item) ...

prompt> ()j
()j : Joe

prompt> (7)j
(7)j : Joe

A way to hide constructors from the surface syntax.

Original comment by ggr...@gmail.com on 18 Dec 2010 at 2:13

[GoogleCodeExporter]

As of r445 we also have LeftRecords!

Original comment by ggr...@gmail.com on 27 Dec 2010 at 10:15

[GoogleCodeExporter]

see checkDerivs in Infer.hs where to apply the fix.

Original comment by ggr...@gmail.com on 1 Jan 2011 at 11:46

[GoogleCodeExporter]

Issue 77 has been merged into this issue.

Original comment by ggr...@gmail.com on 1 Jan 2011 at 11:47

[GoogleCodeExporter]

I have probably changed my mind, syntactical convention should not imply 
semantics.
But! When we can prove that the types always line up nicely, then we can 
probably use a more efficient internal representation, as for Nat-like 
datatypes we can switch to the 'repeated-constructor' scheme:

Vcon' Var Int V

Where the Int specifies the count of nested 'successor' constructors.

Original comment by ggr...@gmail.com on 8 Sep 2011 at 9:51