Re: Call to arms: lambda-case is stuck and needs your help
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my preferences in order (all are single argument versions):
1: Omission: "case of". There seems to be some support for this but it
was not included in the summary.
2: Omission with clarification: "\case of"
3: "\of" - but I think this is a little weird. It's nice to have
short keywords but not at the expense of intuition. The goal here is
to drop the variable name not the case keyword, right?
Regards,
Jonas
On 7 July 2012 06:08, Tyson Whitehead wrote:
> On July 6, 2012 11:49:23 Tyson Whitehead wrote:
>> Currently it depends on the depth of this new level of indentation relative
>> to all the groupings started on that line. I think most people would
>> expect it to just apply to the last grouping though. That is
>>
>> where { f x = do {
>> stmt1
>> stmt2
>> } }
>>
>> mask $ let { x = do {
>> stmt1
>> stmt2
>> } }
>>
>> The rule in this case would be that if the grouping began on a newline that
>> is idented farther then the previous line, the grouping is assocated with
>> the grouping token and when it closes, it closes all those deeper than
>> itself.
>
> I've thought some more about this and it seems to me that there are two ways
> people might intuitively think about doing grouping via indentation.
>
> 1 - the first item is on the same line and subsequent ones are lined up with
> it
>
> do stmt1
> stmt2
>
> 2 - the first item is on a new line and subsequent ones are lined up with it.
>
> do
> stmt1
> stmt2
>
> The current layout engine is targeted at (1). It appears to do (2), but it is
> not really reliable as things start to go south if the first line happened to
> open more than one grouping (precisely the problem that make '\' a group token
> would introduce in codes). For an example, consider
>
> let greet name = do
> putStr "hello "
> putStrLn name
> in f "world"
>
> It currently translates into
>
> let { greet name = do {} } putStr "hello " putStrLn name in f "world"
>
> This results in an unituituve "Empty 'do' construct" error message.
>
> I propose we detected (2) and make it work too. That is, if the line ends
> with a grouping construct and the next line is indented relative to that line,
> then assume we really don't want '{}' and instead always start grouping (even
> if it isn't indented further than other possible groupings also started).
>
> In other words, translate the above into
>
> let { greet name = do {
> putStr "hello";
> putStrLn name
> }} in f "world"
>
> This would then correctly handle the problamatic case raised in wiki where
>
> mask $ \restore -> do
> stmt1
> stmt2
>
> is in translated into
>
> mask $ \ { restore -> do {} } stmt1 stmt2
>
> under the current rules if '\' is made a grouping token.
>
> The very limited scope of this (i.e., it would only apply to lines that end
> with a grouping construct where the next line is indented further than that
> line) should also address Simon's concerns regarding things like
>
>f x y = x + y
> where -- I just left this where here by accident
>
>g x = ...
>
> and
>
>instance Exception Foo where
>instance Exception Bar
>
> Cheers! -Tyson
>
> PS: To be fully precise, the modified layout decoder in 9.3 would be
>
> L (:ts) i (m:ms) = ; : (L ts n (m:ms)) if m = n
> = } : (L (:ts) n ms) if n < m
> L (:ts) i ms = L ts n ms
> L ({n}::ts) i ms = { : (L ts n (n:ms)) if n > i (new rule)
> L ({n}:ts) i (m:ms) = { : (L ts i (n:m:ms)) if n > m (Note 1)
> L ({n}:ts) i [] = { : (L ts i [n]) if n > 0 (Note 1)
> L ({n}:ts) i ms = { : } : (L (:ts) i ms) (Note 2)
> L (}:ts) i (0:ms) = } : (L ts i ms) (Note 3)
> L (}:ts) i ms = parse-error (Note 3)
> L ({:ts) i ms = { : (L ts i (0:ms)) (Note 4)
> L (t:ts) i (m:ms) = } : (L (t:ts) i ms) if m /= 0 and parse-error(t)
> (Note 5)
> L (t:ts) i ms = t : (L ts i ms)
> L [] i [] = []
> L [] i (m:ms) = } : L [] i ms if m /= 0 (Note 6)
>
> http://www.haskell.org/onlinereport/syntax-iso.html
>
> As before, the function 'L' maps a layout-sensitive augmented token stream to
> a non-layout-sensitive token stream, where the augmented token stream includes
> '' and '{n}' to, respectively, give the indentation level of the first
> token
> on a new line and that following a grouping token not followed by '{'.
>
> This time though, we allow the '{n}' '' sequence (before it was supressed
> to just '{n}'). We also add a new state variable 'i' to track the indentation
> of the current line. The new rule now opens a grouping over a newline so
> long as the indentation is greater than the current line.
>
> Upon a less indented line, it will then close all currently open groups with
> an indentation less than the new line.
>
>
Re: [GHC Users] Dictionary sharing
Thank you for your response Edward, You write that it is usually only evaluated once, do you know the circumstances under which it is evaluated more than once? I have some examples of this but they are all very large. The real issue I was having was actually not with a list but with a memoised function i.e. something like: >>> class C a where memoised :: Int -> a <<< Perhaps functions are treated differently? Regards, Jonas On 29 June 2012 15:55, Edward Z. Yang wrote: > Hello Jonas, > > Like other top-level definitions, these instances are considered CAFs > (constant applicative forms), so these instances will in fact usually > be evaluated only once per type X. > > import System.IO.Unsafe > class C a where > dflt :: a > instance C Int where > dflt = unsafePerformIO (putStrLn "bang" >> return 2) > main = do > print (dflt :: Int) > print (dflt :: Int) > print (dflt :: Int) > > ezyang@javelin:~/Dev/haskell$ ./caf > bang > 2 > 2 > 2 > > Cheers, > Edward > > Excerpts from Jonas Almström Duregård's message of Fri Jun 29 07:25:42 -0400 > 2012: >> Hi, >> >> Is there a way to ensure that functions in a class instance are >> treated as top level definitions and not re-evaluated? >> >> For instance if I have this: >> >>> >> class C a where >> list :: [a] >> >> instance List a => List [a] where >> list = permutations list >> <<< >> How can I ensure that list :: [[X]] is evaluated at most once for any >> type X (throughout my program)? >> >> I assume this is potentially harmful, since list can never be garbage >> collected and there may exist an unbounded number of X's. >> >> I currently have a solution that uses Typeable to memoise the result >> of the function based on its type. Is there an easier way? >> >> Regards, >> Jonas >> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[GHC Users] Dictionary sharing
Hi, Is there a way to ensure that functions in a class instance are treated as top level definitions and not re-evaluated? For instance if I have this: >>> class C a where list :: [a] instance List a => List [a] where list = permutations list <<< How can I ensure that list :: [[X]] is evaluated at most once for any type X (throughout my program)? I assume this is potentially harmful, since list can never be garbage collected and there may exist an unbounded number of X's. I currently have a solution that uses Typeable to memoise the result of the function based on its type. Is there an easier way? Regards, Jonas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass defaults
or discussed below), > just like RankNTypes subsumes Rank2Types. > I further propose that GHC enables SilentDefaultSuperInstances by default, > as a pragmatic choice to avoid legacy issues, but not DefaultSuperInstances. > If (only) SilentDefaultSuperInstances is enabled, I propose that Option 2 is > used. It makes perfect sense to warn if you override a default instance, > just like it is sensible to warn about name shadowing. Option 3 strikes me > as strictly worse. However, if DefaultSuperInstances is enabled (which must > then be done explicitly), I propose that Option 1 is used instead. > > 2011/9/2 Conor McBride >> >> On 2 Sep 2011, at 18:19, Jonas Almström Duregård wrote: >> >> The recent discussion concerns whether option 2 should eventually be >> shifted to option 1. Everyone seems to agree that option 2 should be >> used initially. > > > With my proposal this discussion becomes moot. SilentDefaultSuperInstances > effects option 2, DefaultSuperInstances effects option 1. The discussion can > then instead turn to whether or not DefaultSuperInstances should be adopted > in Haskell', and (only) at that point there will be an automatic switch to > option 1. >> >> A similar warning should perhaps indicate that a "hiding" clause has >> nothing to hide, as Jonas suggests. > > Yes, I agree with this. > >> >> I'm in favour of Option 2 now and Option 1 later, where "later" has >> non-disruptiveness criteria attached. A bit like being in favour of >> the pound now and the euro later. > > ... and the proper transition process from one to the other is the Haskell' > process. > What sayeth ye all? > Cheers, > /Niklas > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass defaults
I agree. Option 2 FTW :) The recent discussion concerns whether option 2 should eventually be shifted to option 1. Everyone seems to agree that option 2 should be used initially. Regards, Jonas On 2 September 2011 18:55, Simon Peyton-Jones wrote: > Too many words! I'm losing track. What I'm proposing is Option 2 under "The > design of the opt-out mechanism" on > http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances > > I believe that meets everyone's goals: > * A warning encourages you to fix the client code > * But you can turn it off, and it's not fatal. > > Does anyone advocate something else? > > Simon > > | -Original Message- > | From: glasgow-haskell-users-boun...@haskell.org > [mailto:glasgow-haskell-users- > | boun...@haskell.org] On Behalf Of Jonas Almström Duregård > | Sent: 02 September 2011 16:50 > | To: Conor McBride > | Cc: GHC users > | Subject: Re: Superclass defaults > | > | > The question then comes down to whether that warning should ever be > | > strengthened to an error. > | > | Indeed. > | > | > I agree that such a scenario is possible. The present situation gives > | > no choice but to do things badly, but things often get done badly the > | > first time around anyway. Perhaps I'm just grumpy, but I think we > | > should aim to make bad practice erroneous where practicable. Once > | > the mistake is no longer forced upon us, it becomes a mistake that > | > deserves its penalty in labour. Silent pre-emption is bad practice and > | > code which relies on it should be fixed: it's not good to misconstrue > | > an instance declaration because you don't know which instance > | > declarations are somewhere else. Nonmonotonic reasoning is always a > | > bit scary. > | > > | > From a library design perspective, we should certainly try to get these > | > hierarchical choices right when we add classes. I accept that it should > | > be cheap to fix mistakes (especially when the mistake is lack of > | > foresight. Sticking with the warning rather than the error reduces the > | > price of this particular legacy fix at the cost of tolerating misleading > | > code. I agree that the balance of this trade-off is with the warning, > | > for the moment, but I expect it to shift over time towards the error. > | > But if it's clear what the issue is, then we can at least keep it under > | > review. > | > | I agree. Making bad practice erroneous is good, but its not really the > | bad practice that raises the error here. You have no serious problems > | until you try to change your bad design to a good one. Like you say it > | should be cheap to fix mistakes. > | > | >> Will there be a solution to this dilemma that I have missed? Should > | >> the client code be allowed opt-out from the superclass preemptively > | >> before it is given a default? Won't that cause a similar perplexity? > | > > | > I don't know what you mean by this. Perhaps you could expand on it? > | > | What I'm trying to ask is if you can write compatible code that will > | work across gradual changes of the compiler and the libraries. > | > | Suppose we have library with class C. In a newer version of the > | library we add an intrinsic superclass S. Also suppose the compiler > | implements option 1. Now the users of the library want to write code > | that uses both C and S, and that's compatible with both the new and > | the old library. From what I can tell there are three situations that > | needs to be covered: > | > | 1) Old compiler - Old library > | Here we need to specify both instances, and we cant hide the default S > | instance because its not supported by the compiler. This also applies > | for other situations where the client must use Haskell 2010 compatible > | code. > | > | 2) New compiler - Old library > | Here we also need to specify both instances. > | > | 3) New compiler - New library > | We can either write both instances and hide the default or we can just > | write an instance for C. > | > | Clearly code that covers situation 1 will never be compatible with > situation 3. > | > | The question I was asking was if we are allowed to hide the default > | instance of S in situation 2. In that case you can write compatible > | code for situation 2 and 3. The possible confusion from this is that > | you hide a default implementation thats not defined. Maybe it's not as > | bad as overriding silently, but there is some room for error where you > | think you have blocked a superclass instance but really you have just > | blocked some completely unrelated cl
Re: Superclass defaults
> The question then comes down to whether that warning should ever be > strengthened to an error. Indeed. > I agree that such a scenario is possible. The present situation gives > no choice but to do things badly, but things often get done badly the > first time around anyway. Perhaps I'm just grumpy, but I think we > should aim to make bad practice erroneous where practicable. Once > the mistake is no longer forced upon us, it becomes a mistake that > deserves its penalty in labour. Silent pre-emption is bad practice and > code which relies on it should be fixed: it's not good to misconstrue > an instance declaration because you don't know which instance > declarations are somewhere else. Nonmonotonic reasoning is always a > bit scary. > > From a library design perspective, we should certainly try to get these > hierarchical choices right when we add classes. I accept that it should > be cheap to fix mistakes (especially when the mistake is lack of > foresight. Sticking with the warning rather than the error reduces the > price of this particular legacy fix at the cost of tolerating misleading > code. I agree that the balance of this trade-off is with the warning, > for the moment, but I expect it to shift over time towards the error. > But if it's clear what the issue is, then we can at least keep it under > review. I agree. Making bad practice erroneous is good, but its not really the bad practice that raises the error here. You have no serious problems until you try to change your bad design to a good one. Like you say it should be cheap to fix mistakes. >> Will there be a solution to this dilemma that I have missed? Should >> the client code be allowed opt-out from the superclass preemptively >> before it is given a default? Won't that cause a similar perplexity? > > I don't know what you mean by this. Perhaps you could expand on it? What I'm trying to ask is if you can write compatible code that will work across gradual changes of the compiler and the libraries. Suppose we have library with class C. In a newer version of the library we add an intrinsic superclass S. Also suppose the compiler implements option 1. Now the users of the library want to write code that uses both C and S, and that's compatible with both the new and the old library. From what I can tell there are three situations that needs to be covered: 1) Old compiler - Old library Here we need to specify both instances, and we cant hide the default S instance because its not supported by the compiler. This also applies for other situations where the client must use Haskell 2010 compatible code. 2) New compiler - Old library Here we also need to specify both instances. 3) New compiler - New library We can either write both instances and hide the default or we can just write an instance for C. Clearly code that covers situation 1 will never be compatible with situation 3. The question I was asking was if we are allowed to hide the default instance of S in situation 2. In that case you can write compatible code for situation 2 and 3. The possible confusion from this is that you hide a default implementation thats not defined. Maybe it's not as bad as overriding silently, but there is some room for error where you think you have blocked a superclass instance but really you have just blocked some completely unrelated class. Of course we can get compatibility across all three using CPP but I really wish we won't need that. As time passes, situation 1 will become more rare, although situation 2 and 3 can reoccur endlessly as new libraries are designed and redesigned. Regards, Jonas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass defaults
Hi, On 31 August 2011 12:22, Conor McBride wrote: > I become perplexed very easily. I think we should warn whenever silent > pre-emption (rather than explicit) hiding is used to suppress a default > instance, because it is bad --- it makes the meaning of an instance > declaration rather more context dependent. Perhaps a design principle > should be that to understand an instance declaration, you need only > know (in addition) the tower of class declaration s above it: it is > subtle and worrying to make the meaning of one instance declaration > depend on the presence or absence of others. Those are all good arguments, and you've convinced me that always warning is better. > Arguably, option 1 does not conflict with design goal 1. Design goal 1 > supports a methodology for refining a class into a hierarchy without > creating the need for stacks of default instances or breaking code. If > the new superclass is a brand new thing without legacy instances, > there's no problem. If we'd had this mechanism in place, Functor would > always have been made a superclass of Monad, Applicative would have > been easily inserted, and we wouldn't have the stacks of manually added > default instances to worry about. > > The main problem with Option 1 is in dealing with the legacy of > classes which currently require a stack of default instances, creating > a hierarchy from parts which already exist. Option 1 would create a bunch > of instance conflicts and thus demand changes to code. Design goal 1 > isn't very explicit (sorry!) about this distinction between introducing > new classes as superclasses and building hierarchies from legacy classes, > but it was the former I intended. I always expected the latter to cause > trouble. > > If it is also a design goal to minimize damage with respect to the > current unfortunate situation, then Option 1 is problematic. Whatever we > might wish, we are where we are. We should be pragmatic. I think we > should set Option 1 as the direction of travel, but go with Option 2 for > the moment. We should make sure that the warnings generated by Option 2 > are sufficiently informative that it is easy to track down the conflicts > and resolve them explicitly, for Option 1 compliance. First of all, I think the design goal is quite clear: "a class C can be re-factored into a class C with a superclass S, without disturbing any clients". Requiring client C to opt-out from the default implementation of S is a clear violation of the design goal. So I disagree that option 1 can be compatible with the design goal, but like you say the design goal might be at fault. Also, if I understand you correctly, you say the current situation is exceptional, and suggest option 2 as a temporary solution to it. You seem convinced that these kind of situations will not appear in the future, but I'm not as optimistic about that. Even when superclass defaults are implemented, people will occasionally implement classes without realizing that there is a suitable intrinsic superclass (or add the superclass but not the default instance). People will start using the new class and give separate instances for the superclass, and eventually someone will point out that the there should be a default instance for the superclass. Now if option 1 is implemented, the library maintainers will be reluctant to add the superclass instance because it will break a lot of client code. Will there be a solution to this dilemma that I have missed? Should the client code be allowed opt-out from the superclass preemptively before it is given a default? Won't that cause a similar perplexity? Regards, Jonas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass defaults
| > There seems to be a lot of support for Option 3... but what about Option 2 (ie pre-empt but give a warning)? I think option 2 sounds very good. Possibly with the exception of only warning when the manual instance is in another module, since you will never experience the "perplexity" described in option 3 if you have written the instance yourself. This means that most modules will not get any warning when a class is changed to give a default superclass instance. Even omitting the warning only when the instantiated datatype is in the same module as the instances might be enough to suppress most warnings. Also i wonder if there will be a way of suppressing the warnings and still have compatible code (with the current compiler, preferably without using CPP)? /J On 31 August 2011 09:21, Simon Peyton-Jones wrote: > | > Won't option 1 "Reject this as a duplicate instance declaration, which > | > indeed it is." conflict with design goal 1: "a class C can be > | > re-factored into a class C with a superclass S, without disturbing any > | > clients"? > > Yes, option 1 does conflict with design goal 1; good point. There seems to > be a lot of support for Option 3... but what about Option 2 (ie pre-empt but > give a warning)? > > I've updated the wiki page > http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances to > reflect this discussion. > > Simon > > > | -Original Message- > | From: glasgow-haskell-users-boun...@haskell.org > [mailto:glasgow-haskell-users- > | boun...@haskell.org] On Behalf Of Sebastian Fischer > | Sent: 30 August 2011 03:49 > | To: Bas van Dijk > | Cc: glasgow-haskell-users@haskell.org; Simon Peyton-Jones > | Subject: Re: Superclass defaults > | > | On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk wrote: > | > | > Won't option 1 "Reject this as a duplicate instance declaration, which > | > indeed it is." conflict with design goal 1: "a class C can be > | > re-factored into a class C with a superclass S, without disturbing any > | > clients"? > | > | If yes, I prefer option 3: > | > | > "Allow the explicit to supersede the intrinsic default silently". > | > | The argument against this option is: > | > | > I might notice > | > that Foo is a monad and add a Monad Foo instance in my own code, > | > expecting the Applicative Foo instance to be generated in concert; to > | > my horror, I find my code has subtle bugs because the package > | > introduced a different, non-monadic, Applicative Foo instance which > | > I'm accidentally using instead. > | > | This seems rare enough that it's feasible to issue a warning if a > | default instance is overwritten by an explicit instance in a different > | module which would prevent the described perplexity. This wouldn't, > | for example, disturb the transformers example mentioned by Bas because > | (I think) all instances are defined in the same module. > | > | Sebastian > | > | ___ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass defaults
Hi, First of all, I love the idea of default superclass instances! About the opt-out feature, the problem with option 3 is only present if the superclass instance is defined in another module (you won't see unexpected behavior from your own instances). One solution is to use option 3 if the offending is defined in the same module and reject/warn only when there is a superclass instance in another module. This way users are not surprised when the compiler rejects a Functor/Applicative pair because they need to explicitly tell it to hide the intrinsic Functor, and the case that Functor and Applicative instances are defined in separate modules must be relatively rare (outside the Applicative library)? We might even require the data type to be defined in the same module (which i guess is easier to check and still very common) to silently override a default? Documenting this feature might not be very pretty i guess... I think the most important thing is to enable users to write compatible code, i.e. modules that works with the Applicative class whether it defines a default Functor or not. I suppose if option 1 is used, hiding should be allowed even for classes that would not have been defined anyway (with a warning)? If we allow the Multi-headed instance declarations described in the suggestion then we can always write compatible code by merging instances, since an instance for (Functor,Applicative) would always hide the default Functor instance if there is one (right?). Regards, Jonas On 28 August 2011 23:21, Bas van Dijk wrote: > On 22 August 2011 10:10, Simon Peyton-Jones wrote: >> | > I don't completely understant how does it work. Does client need to >> enable >> | > language extension to get default instances? >> | >> | I think that the extension would only be required to *define them*, >> | not for them to be generated. The more conservative choice would >> | indeed be to require the extension for both, though. >> >> Yes. I've clarified >> http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances to say >> this. >> >> | > Also proposal cannot fix Functor/Applicative/Monad problem without >> breaking >> | > client code. It requires explicit opt-out but client may define >> Applicative >> | > instance. And unless "hiding" is added it will result in compile error. >> | >> | I think the intention (at least as I understand it) is that a >> | superclass default is only used to generate an instance if there is >> | not already some suitable instance in scope, just like a default >> | method is only used if there is not some explicit definition for the >> | method in the instance. >> >> Actually that is not what Conor and I proposed. See >> http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances. Under >> "Variations" we discuss the "silent-opt-out" choice. But it's bad enough >> knowing exactly what instances are in scope (given that they are not named), >> let alone having that control what further instances are or are not >> generated! For superclass defaults there is no such ambiguity. >> >> Simon >> >> >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > Won't option 1 "Reject this as a duplicate instance declaration, which > indeed it is." conflict with design goal 1: "a class C can be > re-factored into a class C with a superclass S, without disturbing any > clients"? > > Take the transformers package for example. It defines lot's of > instances of Functor and Applicative for its monad transformers. > Doesn't transformers have to be changed if we go for option 1 (by > either dropping the Functor and Applicative instances or listing > hiding clauses in the Monad instances) thereby seriously conflicting > with the design goal of not disturbing any clients. > > I expected the semantics to be like option 3: "Allow the explicit to > supersede the intrinsic default silently". It has the advantage of: > > 1) Not disturbing any client code. > > 2) Giving the ability to define optimized implementations if you're > not happy with the default ones (without using the hiding mechanism). > > 3) Feeling very much like the semantics of default methods thereby > conforming to the rule of least surprise. > > The argument against option 3, which I quote: > > "Option 3 avoids that problem but risks perplexity: if I make use of > some cool package which introduces some Foo :: * -> *, I might notice > that Foo is a monad and add a Monad Foo instance in my own code, > expecting the Applicative Foo instance to be generated in concert; to > my horror, I find my code has subtle bugs because the package > introduced a different, non-monadic, Applicative Foo instance which > I'm accidentally using instead." > > talks about "subtle bugs". Could you give an example of such a bug? > > I would expect that the non-monadic Applicative Foo instance i
Re: Quoting a quasi-quote
Hi,
I have an alternative suggestion, please let me know what you think.
We introduce an alternative start tag i.e. a quote can start with [q|
or [q\| (or something similar). If [q| is used then the quoted text is
used verbatim and if the alternative start-tag is used then the escape
sequences suggested (\\ and \|]) are enabled.
Examples:
These are all as in the current implementation:
[q|nothing special|]
[q|a \ in the text|] (uses "a \\ in the text")
These is an incompatible change:
[q|a \|] |] will be a parse error, is currently "a |] "
These are all parse errors (I believe) that will work:
[q|a \|] will use "a \\"
[q\|nothing special|] will use "nothing special"
[q\|a \\ in the text|] will use "a \\ in the text"
[q\|both \|] and \\|] will use "both |] and \\"
Also [q\|a \ in the text|] should be a parse error, i.e. all
backslashes must be escape sequences when using the alternative tag.
Arguably the incompatible change could be removed, but then the
alternative tag must be used to end a quote with backslash and it
seems cleaner to have one fully verbatim and one fully escapable tag.
One advantage of this approach is that we can add more escape
sequences in the future without breaking code (since all backslash
sequences are reserved in the alternative tag).
Regards,
Jonas
On 27 July 2011 08:56, Simon Peyton-Jones wrote:
> Dear Template Haskell users
>
> There was a little exchange about TH quasiquotes a few weeks back (see
> below). I've made a ticket and some concrete proposals here
> http://hackage.haskell.org/trac/ghc/ticket/5348
>
> Do take a look, if you care about TH quasiquotes.
>
> Simon
>
> | -Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org
> [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Simon Marlow
> | Sent: 11 July 2011 13:43
> | To: g...@sefer.org
> | Cc: GHC users; Ben Millwood
> | Subject: Re: Quoting a quasi-quote
> |
> | On 30/06/2011 14:52, Yitzchak Gale wrote:
> | > It was pointed out by Ben Millwood on the Cafe
> | > that there is an undocumented way to escape the
> | > closing oxford bracket of a quasi-quote using
> | > a backslash:
> | >
> | > [s|This quasi-quote contains this, \|], an escaped
> | > closing oxford bracket.|]
> | >
> | > The backslash itself cannot be escaped in this
> | > way:
> | >
> | > [s|Also contains an escaped bracket \\|] |]
> | >
> | > Thus there is a fairly strong limitation on the
> | > contents of a quasi-quote: it can never end
> | > in a backslash.
> | >
> | > This behavior is not mentioned in the GHC docs.
> | > Is it a mistake, or is it meant to be a supported
> | > feature?
> | >
> | > This behavior is a bit surprising to me. Since the
> | > whole point of a quasi-quoter is to allow the user
> | > to define syntax, you would think that the syntax
> | > for the quasi-quote itself would be as quiet as
> | > possible and stay out of the way. People who
> | > need to be able to escape the closing bracket
> | > can easily define their own syntax to do so.
> | >
> | > In any case, if this is indeed a feature, it certainly
> | > should be documented.
> |
> | It looks intentional to me:
> |
> | lex_quasiquote :: String -> P String
> | lex_quasiquote s = do
> | i <- getInput
> | case alexGetChar' i of
> | Nothing -> lit_error i
> |
> | Just ('\\',i)
> | | Just ('|',i) <- next -> do
> | setInput i; lex_quasiquote ('|' : s)
> | | Just (']',i) <- next -> do
> | setInput i; lex_quasiquote (']' : s)
> | where next = alexGetChar' i
> |
> | Just ('|',i)
> | | Just (']',i) <- next -> do
> | setInput i; return s
> | where next = alexGetChar' i
> |
> | Just (c, i) -> do
> | setInput i; lex_quasiquote (c : s)
> |
> |
> | Indeed, it also seems strange that "\\]" is interpreted as "]".
> |
> | That's all I know. I agree we should either document or remove the feature.
> |
> | Cheers,
> | Simon
> |
> |
> | ___
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users@haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reloading and templates
Hi,
In ghci, if you change a module that exports a TH template it will not
recompile modules that use the template. Example:
-- In A.hs
{-#LANGUAGE TemplateHaskell#-}
module A where
import Language.Haskell.TH
a = [d|x = 5|]
-- in B.hs
{-#LANGUAGE TemplateHaskell#-}
import A
a
-- As expected in ghci B.hs:
*Main> x
5
-- But if i change the def. of a to [d|x = 4|] and do :r
[1 of 2] Compiling A( A.hs, interpreted )
Ok, modules loaded: A, Main.
*Main> x
5
The only workaround i know is to reload all modules. I assume you have the
same problem when compiling with ghc. This has caused headaches for me on
several occasions lately, is there a ticket for it or should i submit one?
Regards,
Jonas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Template Haskell and linking
Hi GHC users! Does anyone know if an import that is only used by Template Haskell (i.e. not in "actual" code) is reflected in the produced executable? Example: import LargeModule(thFunction) $thfunction ... Is LargeModule linked in the executable file? (Assume thFunction is not referenced by the code it generates or elsewhere in the example) Best regards Jonas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
