From Per.Lindgren at ltu.se Sun May 2 17:41:20 2010 From: Per.Lindgren at ltu.se (Per Lindgren) Date: Sun May 2 17:08:23 2010 Subject: [Timber] Bindings Message-ID: Hi Consider: ------------- module Err1 where import POSIX root :: RootType root w = do env = new posix w temp = "12" temp = "abc" env.stdout.write (show temp) What is the defined behavior? (The result using timberc is no compiler error and the output "12" when executed. If that is what's intended, then we might be in for some confused programmers. ) /Per From kruglyak at mac.com Sun May 2 19:44:57 2010 From: kruglyak at mac.com (Andrey Kruglyak) Date: Sun May 2 19:12:11 2010 Subject: [Timber] Bindings In-Reply-To: References: Message-ID: <1E159A0E-A87B-4EC2-A5D3-B2A3EEC1E455@mac.com> Hi! This must be a bug (and one that should be fixed ASAP), not only because it's not how we define bindings (a name can only be bound once), but also because if we separate the two definitions of "temp" we do get a compile error "duplicate variable": import POSIX root :: RootType root w = do temp = "12" env = new posix w temp = "abc" env.stdout.write (show temp) I hope that Johan can fix it soon. Regards, Andrey On May 2, 2010, at 23:41, Per Lindgren wrote: > Hi > > Consider: > ------------- > module Err1 where > > import POSIX > > root :: RootType > root w = do > env = new posix w > temp = "12" > temp = "abc" > env.stdout.write (show temp) > > What is the defined behavior? > > (The result using timberc is no compiler error and the output "12" when executed. If that is what's intended, then we might be in for some confused programmers. ) > > /Per > > > _______________________________________________ > Timber mailing list > Timber@haskell.org > http://www.haskell.org/mailman/listinfo/timber ------------------------------------------------------------------------ Andrey Kruglyak PhD student http://www.andreykruglyak.com Dept. of Computer Science and Electrical Engineering Lulea University of Technology, Lulea, Sweden T +46 920 49 23 57 (office) T +46 706 16 76 03 (mobile) Office A2314 (A-huset) From kruglyak at mac.com Sun May 2 20:54:11 2010 From: kruglyak at mac.com (Andrey Kruglyak) Date: Sun May 2 20:21:12 2010 Subject: [Timber] Bindings In-Reply-To: <1E159A0E-A87B-4EC2-A5D3-B2A3EEC1E455@mac.com> References: <1E159A0E-A87B-4EC2-A5D3-B2A3EEC1E455@mac.com> Message-ID: Oh, when two name bindings follow one another, this is probably seen as an extreme form of pattern matching, just as when we define a function on more than one line. On the other hand, maybe the compiler should detect that there are no arguments and consider this an error? And what is the correct behavior for: A x = z B x = z (assuming z is a value of the data type D = A Int | B Int)? Should the first line cause an exception if z is B 4, or should the second line succeed? Andrey Sent from my iPhone On May 3, 2010, at 1:44, Andrey Kruglyak wrote: > Hi! > > This must be a bug (and one that should be fixed ASAP), not only because it's not how we define bindings (a name can only be bound once), but also because if we separate the two definitions of "temp" we do get a compile error "duplicate variable": > > import POSIX > > root :: RootType > root w = do > temp = "12" > env = new posix w > temp = "abc" > env.stdout.write (show temp) > > I hope that Johan can fix it soon. > > Regards, > Andrey > > On May 2, 2010, at 23:41, Per Lindgren wrote: > >> Hi >> >> Consider: >> ------------- >> module Err1 where >> >> import POSIX >> >> root :: RootType >> root w = do >> env = new posix w >> temp = "12" >> temp = "abc" >> env.stdout.write (show temp) >> >> What is the defined behavior? >> >> (The result using timberc is no compiler error and the output "12" when executed. If that is what's intended, then we might be in for some confused programmers. ) >> >> /Per >> >> >> _______________________________________________ >> Timber mailing list >> Timber@haskell.org >> http://www.haskell.org/mailman/listinfo/timber > > ------------------------------------------------------------------------ > Andrey Kruglyak > PhD student > > http://www.andreykruglyak.com > > Dept. of Computer Science and Electrical Engineering > Lulea University of Technology, Lulea, Sweden > T +46 920 49 23 57 (office) > T +46 706 16 76 03 (mobile) > Office A2314 (A-huset) > > _______________________________________________ > Timber mailing list > Timber@haskell.org > http://www.haskell.org/mailman/listinfo/timber From Per.Lindgren at LTU.SE Mon May 3 01:52:57 2010 From: Per.Lindgren at LTU.SE (Per Lindgren) Date: Mon May 3 01:19:59 2010 Subject: [Timber] Bindings In-Reply-To: References: <1E159A0E-A87B-4EC2-A5D3-B2A3EEC1E455@mac.com> Message-ID: <2B5275EC-1E9F-4A0B-AC31-02AC46CA3C24@LTU.SE> Hi On May 3, 2010, at 2:54 AM, Andrey Kruglyak wrote: > Oh, when two name bindings follow one another, this is probably seen as an extreme form of pattern matching, just as when we define a function on more than one line. Yes, I think this could be seen as an extreme for overlapping patterns. At least Haskell makes an attempt warning the programmer of such patterns, I do not know if it is left out in timberc deliberately or if it is to be considered a bug. Johan once mentioned this as a hard problem to solve in general, but at least some obvious overlapping patterns should be brought to the programmers attention. /Per > > On the other hand, maybe the compiler should detect that there are no arguments and consider this an error? And what is the correct behavior for: > > A x = z > B x = z > > (assuming z is a value of the data type D = A Int | B Int)? Should the first line cause an exception if z is B 4, or should the second line succeed? > > Andrey > Sent from my iPhone > > On May 3, 2010, at 1:44, Andrey Kruglyak wrote: > >> Hi! >> >> This must be a bug (and one that should be fixed ASAP), not only because it's not how we define bindings (a name can only be bound once), but also because if we separate the two definitions of "temp" we do get a compile error "duplicate variable": >> >> import POSIX >> >> root :: RootType >> root w = do >> temp = "12" >> env = new posix w >> temp = "abc" >> env.stdout.write (show temp) >> >> I hope that Johan can fix it soon. >> >> Regards, >> Andrey >> >> On May 2, 2010, at 23:41, Per Lindgren wrote: >> >>> Hi >>> >>> Consider: >>> ------------- >>> module Err1 where >>> >>> import POSIX >>> >>> root :: RootType >>> root w = do >>> env = new posix w >>> temp = "12" >>> temp = "abc" >>> env.stdout.write (show temp) >>> >>> What is the defined behavior? >>> >>> (The result using timberc is no compiler error and the output "12" when executed. If that is what's intended, then we might be in for some confused programmers. ) >>> >>> /Per >>> >>> >>> _______________________________________________ >>> Timber mailing list >>> Timber@haskell.org >>> http://www.haskell.org/mailman/listinfo/timber >> >> ------------------------------------------------------------------------ >> Andrey Kruglyak >> PhD student >> >> http://www.andreykruglyak.com >> >> Dept. of Computer Science and Electrical Engineering >> Lulea University of Technology, Lulea, Sweden >> T +46 920 49 23 57 (office) >> T +46 706 16 76 03 (mobile) >> Office A2314 (A-huset) >> >> _______________________________________________ >> Timber mailing list >> Timber@haskell.org >> http://www.haskell.org/mailman/listinfo/timber > _______________________________________________ > Timber mailing list > Timber@haskell.org > http://www.haskell.org/mailman/listinfo/timber From johan.nordlander at ltu.se Mon May 3 03:45:39 2010 From: johan.nordlander at ltu.se (Johan Nordlander) Date: Mon May 3 03:12:39 2010 Subject: [Timber] Bindings In-Reply-To: <2B5275EC-1E9F-4A0B-AC31-02AC46CA3C24@LTU.SE> References: <1E159A0E-A87B-4EC2-A5D3-B2A3EEC1E455@mac.com> <2B5275EC-1E9F-4A0B-AC31-02AC46CA3C24@LTU.SE> Message-ID: <3D66CE93-7A34-46C2-9B76-F272C76226DD@ltu.se> Well, this is not a hard problem in the technical sense, it's just "hard" to choose between the properties we want. The core of the problem is whether a binding x = exp should be seen as an extreme form of a pattern binding pat = exp (letting pat be the trivial pattern x), or an extreme function binding f pat11 .. pat1n | qual1 = exp1 .. f patj1 .. patjn | qualj = expj (letting f = x and n = 0). Timber has so far followed Haskell by taking the secound route, because it enables the use of guards as in msg | null params = "Hello anybody!" | otherwise = "Hello " ++ concat params (Recall that bindings can occur in local scopes as well, where variables like "params" might be statically unknown.) But of course, this example could just as well be written msg = if null params then "Hello anybody!" else "Hello " ++ concat params Which perhaps is not a high price to pay in order to forbid the obviously erroneous variant msg = "Hello anybody!" msg = "Hello everybody!" And come to think of it: there should be nothing to stop us from switching to the first route above *and* extending the syntax of pattern bindings to pat | qual = exp This would meet both demands, I believe. In any case, I see this as yet another example of the need for a thorough overhaul of Timber's concrete syntax! -- Johan > Hi > > On May 3, 2010, at 2:54 AM, Andrey Kruglyak wrote: > >> Oh, when two name bindings follow one another, this is probably >> seen as an extreme form of pattern matching, just as when we define >> a function on more than one line. > > Yes, I think this could be seen as an extreme for overlapping > patterns. At least Haskell makes an attempt warning the programmer > of such patterns, I do not know if it is left out in timberc > deliberately or if it is to be considered a bug. Johan once > mentioned this as a hard problem to solve in general, but at least > some obvious overlapping patterns should be brought to the > programmers attention. > > /Per > > > > > >> >> On the other hand, maybe the compiler should detect that there are >> no arguments and consider this an error? And what is the correct >> behavior for: >> >> A x = z >> B x = z >> >> (assuming z is a value of the data type D = A Int | B Int)? Should >> the first line cause an exception if z is B 4, or should the >> second line succeed? >> >> Andrey >> Sent from my iPhone >> >> On May 3, 2010, at 1:44, Andrey Kruglyak wrote: >> >>> Hi! >>> >>> This must be a bug (and one that should be fixed ASAP), not only >>> because it's not how we define bindings (a name can only be bound >>> once), but also because if we separate the two definitions of >>> "temp" we do get a compile error "duplicate variable": >>> >>> import POSIX >>> >>> root :: RootType >>> root w = do >>> temp = "12" >>> env = new posix w >>> temp = "abc" >>> env.stdout.write (show temp) >>> >>> I hope that Johan can fix it soon. >>> >>> Regards, >>> Andrey >>> >>> On May 2, 2010, at 23:41, Per Lindgren wrote: >>> >>>> Hi >>>> >>>> Consider: >>>> ------------- >>>> module Err1 where >>>> >>>> import POSIX >>>> >>>> root :: RootType >>>> root w = do >>>> env = new posix w >>>> temp = "12" >>>> temp = "abc" >>>> env.stdout.write (show temp) >>>> >>>> What is the defined behavior? >>>> >>>> (The result using timberc is no compiler error and the output >>>> "12" when executed. If that is what's intended, then we might be >>>> in for some confused programmers. ) >>>> >>>> /Per >>>> >>>> >>>> _______________________________________________ >>>> Timber mailing list >>>> Timber@haskell.org >>>> http://www.haskell.org/mailman/listinfo/timber >>> >>> ------------------------------------------------------------------------ >>> Andrey Kruglyak >>> PhD student >>> >>> http://www.andreykruglyak.com >>> >>> Dept. of Computer Science and Electrical Engineering >>> Lulea University of Technology, Lulea, Sweden >>> T +46 920 49 23 57 (office) >>> T +46 706 16 76 03 (mobile) >>> Office A2314 (A-huset) >>> >>> _______________________________________________ >>> Timber mailing list >>> Timber@haskell.org >>> http://www.haskell.org/mailman/listinfo/timber >> _______________________________________________ >> Timber mailing list >> Timber@haskell.org >> http://www.haskell.org/mailman/listinfo/timber > > _______________________________________________ > Timber mailing list > Timber@haskell.org > http://www.haskell.org/mailman/listinfo/timber >