{- # 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.