ggreif / omega

Automatically exported from code.google.com/p/omega
Other
7 stars 0 forks source link

L and R are not in scope #65

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. type
prompt> L 1
(L 1) : forall 'a.(Int+'a)

2. but:
prompt> L
Not in scope: L

What is the expected output? What do you see instead?
L and R should be also in scope when (L 1) works.

Original issue reported on code.google.com by ggr...@gmail.com on 31 Jul 2009 at 10:22

GoogleCodeExporter commented 9 years ago
-- should be this way but currently does not work:
-- R = primitive
-- L = primitive

-- simple workaround:
l x = L x
r x = R x

prompt> l

<fn> : forall 'a 'b.'a -> ('a+'b)
prompt> r

<fn> : forall 'a 'b.'a -> ('b+'a)

Original comment by ggr...@gmail.com on 14 Jan 2011 at 3:48

GoogleCodeExporter commented 9 years ago
This happens because (+) is a built-in Sigma type, which adheres to special 
rules. Let's see where "L" and "R" are defined evaluation-wise.

Original comment by ggr...@gmail.com on 4 Feb 2011 at 10:00

GoogleCodeExporter commented 9 years ago
Yah, these are reserved words (ParserDef.hs)

sumExpression =
  do { inj <- (reserved "R" >> return True) <|>
              (reserved "L" >> return False)
     ; x <- expr
     ; let f True x = Sum R x
           f False x = Sum L x
     ; return (f inj x)
     }

No idea how they can appear in patterns yet.

One could insert (\a-> L a) for each non-saturated mention of L.

Original comment by ggr...@gmail.com on 4 Feb 2011 at 10:16

GoogleCodeExporter commented 9 years ago
above parsing rule causes this crazy talk:

prompt> Just L 4

(Just (L 4)) : forall 'a.Maybe (Int+'a)

Original comment by ggr...@gmail.com on 4 Feb 2011 at 10:21

GoogleCodeExporter commented 9 years ago
Related issue with "run", "lazy", "check" and "Ex" which are parsed the same 
way:

"check a b" gets parsed as "check (a b)", to wit:

prompt> 3 (lazy 3 5)

In the expression: 3 ((lazy 3 5))
the function has a non-functional type: Int

Ideas how to solve this:

1) suppress <name>s that are reserved
2) on encountering such a reserved name in argument position parse it like a 
lambda? ('Ex' won't work..., 'check' and 'lazy' is doubtful)
3) warn (fail?) when encountering these in non-head position (before creating 
'App')
4) make 'run' a regular builtin function

Original comment by ggr...@gmail.com on 27 Aug 2011 at 1:13

GoogleCodeExporter commented 9 years ago
looks like 4) is already implemented:

prompt> map run

<fn> : forall 'a.[Code 'a] -> ['a]

Can we simply rip out the 'runExp' function and the 'Run' data constructor?

Original comment by ggr...@gmail.com on 27 Aug 2011 at 1:24

GoogleCodeExporter commented 9 years ago
You can perform

  svn log --stop-on-copy ^/branches/reserved-words

to see what I am tinkering with. I might well discard this branch completely, 
or cherry-pick parts of it.

Original comment by ggr...@gmail.com on 27 Aug 2011 at 1:54

GoogleCodeExporter commented 9 years ago
more craziness with reserved words:

prompt> (id if 4)  
Not in scope: if
prompt> let if = 5

prompt> (id if 4) 

In the expression: id if 4
the function has a non-functional type: Int

Original comment by ggr...@gmail.com on 27 Aug 2011 at 2:03

GoogleCodeExporter commented 9 years ago
(let L a = R 6 in  7)

gives
line: 1 column: 6
Not in scope: L

Same when using 'L', 'R' in 'where' clause patterns.

Original comment by ggr...@gmail.com on 29 Aug 2011 at 8:59

GoogleCodeExporter commented 9 years ago
r798 implements (on branch) the evaluating of 'L' and 'R' as the above 
workaround suggests, see commit message.

Original comment by ggr...@gmail.com on 29 Aug 2011 at 10:05

GoogleCodeExporter commented 9 years ago
fixed with revisions r812-r815 and r817-r820

Comments 1-3: r815
Comment 4: r818
Comment 5: r819
Comment 6: r812
Comment 8: r813 (and r814)
Comment 9: (r817)

Original comment by ggr...@gmail.com on 29 Aug 2011 at 5:30