{- # LANGUAGE FreeSections #-} -- with GHC's -F you cannot...
module S27 where
-- <ski>'s example of a pathology of the present context inferencing policy.
-- We'd expect these two expressions to have the same semantics, but sadly
-- they do not. Although it's true that people don't write (f x) y often
-- because left-associativity of application makes the parentheses
-- superfluous, nevertheless...
--
-- However, question: Can we prove that both interpretations can not
-- both be simultaneously well-typed, under all possible circumstances?
-- If so, then the type error is a much better eventuality than the
-- compiler silently accepting code that wasn't intended.
--
-- As for attempting to recognise these particular cases and adjust
-- the contextualisation algorithm to accomodate them, nah, that
-- just feels wrong.
v= f __ y -- = _[ f __ y ]_ = \ a -> f a y
v= (f __) y -- = _[ f __ ]_ y = ( \ a -> f a ) y
--------------------------
v= a $ b __ c $ d -- this works: (= a $ (\ _0 -> b _0 c) $ d)
--------------------------
-- Testing that freesect translation "stops" in the subexpression,
-- if all the __'s are in but one of the subexpressions.
v= [ ((__+2) 3) .. ]
v= [ 1, ((__+2) 3) .. ]
{-
-- Translation is correct but the expressions are erroneous,
-- since there's no way to apply the section, which is inside
-- a list enumeration, to an argument which must be outside.
v= [ (__+2) .. ]
v= [ 1,(__+2) .. ]
-}
--------------------------
--v= [x|x<- __ ] [1..3] -- XXX still a problem, but must be commented-out
-- -- because otherwise freesect runtime error.