Re[2]: Java-like

2006-02-08 Thread Bulat Ziganshin
Hello Ian,

Wednesday, February 08, 2006, 9:28:51 PM, you wrote:
>> nonrecursive let in Haskell so that I could write let x = ...x... in ...,
IL> I would argue that the language should discourage variable shadowing, so
IL> that shadow warnings can be used to find bugs.

i use such shadowing to change variable meaning in a part of code



-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re[2]: Java-like

2006-02-07 Thread Bulat Ziganshin
Hello Ben,

Tuesday, February 07, 2006, 11:21:56 PM, you wrote:

>> {-# OPTIONS_GHC -fglasgow-exts #-}
>> main = do return "xx" >>= ((\x -> print x) :: Show a => a -> IO ())
>> main2 = do return "xx" >>= (\(x:: (forall a . (Show a) => a)) -> print x)
>> main3 = do (x :: forall a . Show a => a) <- return "xx"
>>print x
>> 
>> in this module, only "main" compiles ok

BRG> The other two need "exists" rather than "forall", which isn't supported by 
BRG> GHC. As written, they say that x can produce a value of any type that's an 
BRG> instance of Show, but the value you're binding to x has type String, which 
BRG> can only produce a value via Show String.

that i want to say is what the first variant allows to define type of
'x' in such way that the only Show-specific operations are allowed,
like in the OOP languages when you define something like:

widget x := newLabel "text"

the second and third variant should do the same, to my mind. of
course, you are know all that intrinsics much better. i just can add
that some easier variant of declaring 'x' as having only Show
interface and mothing more will be great. and as i shown, it's only
syntax sugar and don't needs any changes in core language/type system.
i'm right?


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime