- ghc-devs - Haskell.org

trouble with formatted Haddock documentation for new module
by Norman Ramsey 28 Jan '22

28 Jan '22

In a new module I'm writing for GHC, I define a record type that has a ton of named fields. Two of the fields have rather large types. Unfortunately, at least with default settings, the Haddock documentation that is well-nigh unreadable (image attached). Does anyone have a workaround? Hécate? (If it's useful, a draft of the offending module can be found at https://gitlab.haskell.org/ghc/ghc/-/blob/wip/backend-as-record/compiler/GH….) Norman

2 1

Curiosity: What accounts for the growth in the RTS in 9.2?
by Norman Ramsey 27 Jan '22

27 Jan '22

I was chatting with a colleague who asked "How big is GHC's run-time system." In the spirit of "look and find out," I found this: nr@homedog ~/.ghcup> ls -hl **HSrts.a -rw-r--r-- 1 nr nr 8.7M Sep 27 16:13 ghc/8.10.7/lib/ghc-8.10.7/rts/libHSrts.a -rw-r--r-- 1 nr nr 8.8M Sep 27 16:36 ghc/9.0.1/lib/ghc-9.0.1/rts/libHSrts.a -rw-r--r-- 1 nr nr 11M Jan 24 15:06 ghc/9.2.1/lib/ghc-9.2.1/rts/libHSrts.a All these binaries were installed by ghcup using the default settings. Does anybody know what accounts for the big jump from 9.0 to 9.2? Norman

1 0

any luck using "retrie" refactoring tool on GHC sources?
by Norman Ramsey 25 Jan '22

25 Jan '22

I'm trying to use the retrie refactoring tool, but I'm getting a mysterious error message: nr@homedog ~/a/g/compiler [1]> retrie --adhoc "forall x . not (backendNeedn'tLink x) == backendNeedsLink x" parseAdhocs:1:80: error: parse error on input ‘#-}’ retrie: user error (parse failed) The Tool was installed using cabal install; its github page is https://github.com/facebookincubator/retrie/#readme. Has anybody had any success using this tool on the GHC sources? I'd love a workaround, or just advice. Norman

2 2

Not all splices are the same
by David Feuer 24 Jan '22

24 Jan '22

I've been a bit upset by the challenges Template Haskell poses for type inference. For example, (3 :: Int) == $$(...) may typecheck when $$(...) == (3 :: Int) does not. I don't imagine this problem can be solved in general, but I'm rather curious whether it might be possible to solve for "pure" splices, with types that look like forall m. Quote m => Code m a Would it be possible to get full bidirectional inference for these if they were somehow marked specially by the user? For instance, if I wrote $$$e that could mean e should be interpreted as having some type PCode a where newtype PCode a = PCode (forall m. Quote m => a)

2 1

[Haskell] [ANNOUNCE] GHC 9.0.2 released
by Zubin Duggal 23 Jan '22

23 Jan '22

The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/). Download Page: https://www.haskell.org/ghc/download_ghc_9_0_2.html Blog Post: https://www.haskell.org/ghc/blog/20211225-ghc-9.0.2-released.html GHC 9.0.2 adds first class AArch64/Darwin support using the LLVM backend, as well as fixing a number of critical correctness bugs with the 9.0.1 release, along with numerous improvements to compiler performance and memory usage: * First-class support for Apple M1 hardware using GHC's LLVM ARM backend. * Fix a number of incorrect rewrite rules for `fromInteger` (#19345, #20066). * Fix a number of runtime system and GC bugs which typically manifested in crashes (#19417, #19297, #19645, #19667, #18033, #20132, #19715, #20399, #20414, #20649, #19147, #20051, #20093) * Fixes for various compiler performance and memory usage issues (#20134, #13586, #20509, #19668, #19996, #19471) * Improvements and bug fixes for the code generator and optimiser (#18638, #19581, #19700, #19996, #19181, #19822) * Fixes for typechecker bugs (#19410 , #19191, #19522, #19400, #19849) * Bug fixes for the frontend and parser (#19397, #19838, #19518, #19777, #20242, #19786) * Emit warnings if Unicode Bidirectional Formatting characters are found in the source, possibly misleading code reviewers (#20263). * Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `native` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Some previous releases were still linked against the `GMP` library due to a misconfiguration of the builders. * A significant refactoring of `process` fixing numerous bugs mostly on Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)) * Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950). A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/9.0.2/docs/html/users_guide/9.0.2-…. Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket][] if you see anything amiss. Happy Holidays and Happy Hacking! - Zubin

5 8

Strictness/demand info for a Name
by Alejandro Serrano Mena 14 Jan '22

14 Jan '22

Dear all, I’m trying to bring the information about demand and strictness to the Haskell Language Server, but I cannot find a way to do so. I was wondering whether you could help me :) Here’s my understanding; please correct me if I’m wrong: - The analysis runs on Core, so getting this information for the current file would require to run the compiler further than type checking, which is quite expensive, - However, this analysis should somehow use known information about imported functions, which should be readily available somewhere, - If the above is true, what is the simplest way to get the information for imported things? As I mentioned above, I would prefer not to run the compiler further than the type checking phase, since otherwise it gets too expensive for IDE usage. Right now HLS uses the information from the .hie files. In fact, this goes into the more general question of how to show information from different analyses within the IDE; I guess solving the case for strictness/analysis may open the door to more (maybe everything recorded inside a `Id`?) Regards, Alejandro

4 6

Semantics of Cmm `switch` statement?
by Norman Ramsey 12 Jan '22

12 Jan '22

For testing purposes, I created the following Cmm program: myswitch (bits32 n) { switch [0 .. 4] n { case 0, 1: { foreign "C" A(); } case 2: { foreign "C" B(); } case 4: { foreign "C" C(); } default: { foreign "C" D(); } } return (666); } In the original C-- specification, it's pretty clear that when, say, the call to foreign function `A` terminates, the switch statement is supposed to finish and function `myswitch` is supposed to return 666. What actually happens in GHC is that this source code is parsed into a control-flow graph in which execution loops forever, repeating the call. The relevant fragment of the prettyprinted CFG looks like this: {offset ca: // global _c1::I32 = %MO_XX_Conv_W64_W32(R1); //tick src<programs/panic.cmm:(1,21)-(9,1)> switch [0 .. 4] _c1::I32 { case 0, 1 : goto c5; case 2 : goto c7; case 4 : goto c9; default: {goto c3;} } ... c5: // global //tick src<programs/panic.cmm:3:16-35> _c4::I64 = A; call "ccall" arg hints: [] result hints: [] (_c4::I64)(); goto c5; ... } Surprising, at least to me. Is this behavior a bug or a feature? And if it is a feature, can anyone explain it to me? Norman

2 1

convention around pattern synonyms
by Richard Eisenberg 04 Jan '22

04 Jan '22

Hi devs, Maybe I'm just old fashioned, but I've come to find pattern synonyms really confusing. Because pattern synonyms will tend to appear next to proper data constructors in code (and they look just like data constructors), when I see one, I think it *is* a data constructor. This problem was motivated by a recent MR that introduces a new pattern synonym <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7261/diffs#7dcf5b567a6c…> that caught me off-guard. So, I'd like to propose the following convention: Every pattern synonym satisfies one of the following two criteria: 1. The pattern synonym is a member of a set of synonyms/constructors that expresses a view of a type. There would naturally be a `COMPLETE` pragma including the set. `GHC.Types.Var.Inferred` is an example. 2. The pattern synonym begins with the prefix `PS_`. In the end, I'd probably prefer just (2). With Inferred, for example, I've been caught in the past trying to figure just what the constructors of ArgFlag were (there seemed to be too many), until I realized what was going on. Pattern synonyms are useful abstractions. I like them. But my mental model of a pattern match is that it matches the structure of the scrutinee and performs no computation. Pattern synonyms violate both of these assumptions, and so (as a reader) I like to know when to put these assumptions to the side. Future IDE support that could, say, color pattern synonyms differently to regular constructors would obviate the need for this convention. What do others think here? `PS_` is ugly. I don't need something quite so loud and ugly, but it's also easy to remember and recognize. Thanks! Richard

3 7

Re: Avoiding full laziness xform / floating-out (Re: What's the benefit of taking "do" blocks apart? Is there a way to turn that off?)
by Erdi, Gergo 31 Dec '21

31 Dec '21

PUBLIC Ah, at least I've figured out why exactly the simplifier does this (regardless of floating out due to full laziness or not): it is because the definition of the default implementation of (>>) is inlined. I have (>>) defined as such: ma >> mb = ma >>= \_ -> mb So when the simplifier encounters a call site "foo >> bar", it needs to bind "foo" and "bar" to avoid duplication (since "ma" and "mb" could occur multiple times on the right-hand side of (>>)'s definition). This means that the best I can hope for would be to avoid floating out "ma" and "mb", but the variable bindings themselves are unavoidable in the face of inlining (and of course I do want inlining). So I'll need to rethink my approach anyway. -----Original Message----- From: Erdi, Gergo Sent: Thursday, December 30, 2021 12:56 PM To: Matthew Pickering <matthewtpickering(a)gmail.com> Cc: Joachim Breitner <mail(a)joachim-breitner.de>; ghc-devs(a)haskell.org Subject: RE: [External] Re: Avoiding full laziness xform / floating-out (Re: What's the benefit of taking "do" blocks apart? Is there a way to turn that off?) PUBLIC Turning on various Opt_D_dump flags, I can see that this tranformation happens in the first iteration of the simplifier. Looking at GHC.Core.Opt.getCoreToDo, I would guess this corresponds to this line: -- initial simplify: mk specialiser happy: minimum effort please runWhen do_presimplify simpl_gently, If I wrote my own optimisation pass, I'm not sure what it could do to inhibit GHC from doing this transformation later on in its pipeline. And I don't want to give up on the simplifier pipeline completely, since there are parts of it that I very much need. One of them is, unfortunately, the specializer itself -- and that comment in getCoreToDo makes me worried that if I somehow managed to get rid of this transformation (or if I skipped the simplifier pipeline completely and just ran the specializer out-of-band), I would break specialization anyway... -----Original Message----- From: Matthew Pickering <matthewtpickering(a)gmail.com> Sent: Thursday, December 30, 2021 10:42 AM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: Joachim Breitner <mail(a)joachim-breitner.de>; ghc-devs(a)haskell.org Subject: [External] Re: Avoiding full laziness xform / floating-out (Re: What's the benefit of taking "do" blocks apart? Is there a way to turn that off?) Hi Gergo, Sounds like you might be better off writing your own optimisation pass rather than relying on making GHC do what you want. Cheers Matt On Thu, Dec 30, 2021 at 9:05 AM Erdi, Gergo via ghc-devs <ghc-devs(a)haskell.org> wrote: > > PUBLIC > > Hi Joachim, > > Thanks for the hints! > > > Hi Gergo, > > > > Am Dienstag, dem 28.12.2021 um 15:57 +0000 schrieb Erdi, Gergo via > > ghc- > > devs: > > > PUBLIC > > > > phew > > Yeah obviously I'm sitting here not only adding these tags, but also > coming up with the automated systems and also the company policies > forcing the usage of said systems ;) > > > didn't investigate deeper (maybe if you provide a small example I would), but just from looking at this: > > Unfortunately, it's hard to make a small example because this all > lives in bizarro world where "IO" isn't IO, "String" isn't [Char] etc, > so I can't just take the input program and pass it to vanilla GHC. > > > > > * It is generally preferable to turn local lambda expressions > > into top-level functions. This way, instead of dynamically > > allocating a FUN heap object, it's just a static function. > > > > * sat_sKv is an IO expression? Then it is actually a function in a way > > (taking the "State token" as an argument). So the above applies. > > This is "IO" but not GHC's IO, just another type with an opaque > definition and a Monad instance. There's no reason for GHC to think > that sat_sKv would be a function. > > Of course, sat_sKw is necessarily a function since it is the second > argument to bind. But only now I am noticing that even sat_sKw's > definition includes *yet another* floated-out variable: > > sat_sKv = some complicated expression 1 sat_sKu = some complicated > expression 2 sat_sKw = \_ -> sat_sKu main = bindIO sat_sKv sat_sKw > > Here, I don't see why GHC should think that sat_sKv and sat_sKu are > functions. For example, here's the definition of sat_sKu: > > sat_sKu :: IO () > [LclId] > sat_sKu > = let { > sat_sRy [Occ=Once1] :: String > [LclId] > sat_sRy > = let { > sat_sRx [Occ=Once1] :: String > [LclId] > sat_sRx = unpackCStringUtf8# "\n"# } in > let { > sat_sRw [Occ=Once1] :: String > [LclId] > sat_sRw > = case foobar True of { > False -> unpackCStringUtf8# "False"#; > True -> unpackCStringUtf8# "True"# > } } in > sApp# sat_sRw sat_sRx } in > putStrOut sat_sRy > > Here, putStrOut is so opaque that it doesn't even have a definition, > it is merely a name registered into GHC's name tables. So I really > don't see why this looks "function-y" to GHC. > > The reason this is all a problem for me is because I would like to > then interpret all these let-bindings, including the toplevel ones, as > eagerly defined variables. But then there is of course a difference > between > > main = > let a1 = someIOAction1 > a2 = someOtherIOAction2 > a2' = \_ -> a2 > in bindIO a1 a2' > > and > > main = > let a1 = someIOAction1 > a2 = \_ -> someIOAction2 > in bindIO a1 a2 > > because if the *definition* of "a2" throws (not its action), then the > first version will throw immediately whereas the second will only > throw when "main" is *run*, after running "a1". > > > * I think this is the FloatOut pass. You can turn it out using > > -fno-full-laziness. Not sure if some others passes might > > do similar things, though. > > I tried turning off Opt_FullLaziness, but unfortunately I am still > getting the same result. I was also hopeful when I saw there's an > Opt_FloatIn flag, but alas that doesn't change this behaviour either > (and it's turned on by default anyway...) > > I'll try to make a self-contained minimal example next week. > > Thanks, > Gergo > > -----Original Message----- > From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Joachim > Breitner > Sent: Wednesday, December 29, 2021 8:39 PM > To: ghc-devs(a)haskell.org > Subject: [External] Re: What's the benefit of taking "do" blocks apart? Is there a way to turn that off? > > > Hi Gergo, > > Am Dienstag, dem 28.12.2021 um 15:57 +0000 schrieb Erdi, Gergo via > ghc- > devs: > > PUBLIC > > phew > > > I’m seeing ‘do’ blocks getting taking apart into top-level > > definitions, so e.g. > > > > main = do > > some complicated expression 1 > > some complicated expression 2 > > > > is compiled into > > > > sat_sKv = some complicated expression 1 sat_sKw = \_ -> some > > complicated expression 2 main = bindIO sat_sKv sat_sKw > > > > This seems to happen regardless of any common subexpressions, i.e. > > it is not the case that sat_sKv or sat_sKw are used anywhere else. > > > > What is the intended benefit of this floating-out? Is there a > > particular Core-to-Core pass that causes this? Is it possible to > > turn it off? > > > didn’t investigate deeper (maybe if you provide a small example I would), but just from looking at this: > > * It is generally preferable to turn local lambda expressions > into top-level functions. This way, instead of dynamically > allocating a FUN heap object, it’s just a static function. > > * sat_sKv is an IO expression? Then it is actually a function in a way > (taking the “State token” as an argument). So the above applies. > > * I think this is the FloatOut pass. You can turn it out using > -fno-full-laziness. Not sure if some others passes might > do similar things, though. > > Cheers, > Joachim > > > -- > Joachim Breitner > mail(a)joachim-breitner.de > This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

1 0

Avoiding full laziness xform / floating-out (Re: What's the benefit of taking "do" blocks apart? Is there a way to turn that off?)
by Erdi, Gergo 30 Dec '21

30 Dec '21

PUBLIC Hi Joachim, Thanks for the hints! > Hi Gergo, > > Am Dienstag, dem 28.12.2021 um 15:57 +0000 schrieb Erdi, Gergo via ghc- > devs: > > PUBLIC > > phew Yeah obviously I'm sitting here not only adding these tags, but also coming up with the automated systems and also the company policies forcing the usage of said systems ;) > didn't investigate deeper (maybe if you provide a small example I would), but just from looking at this: Unfortunately, it's hard to make a small example because this all lives in bizarro world where "IO" isn't IO, "String" isn't [Char] etc, so I can't just take the input program and pass it to vanilla GHC. > > * It is generally preferable to turn local lambda expressions > into top-level functions. This way, instead of dynamically > allocating a FUN heap object, it's just a static function. > > * sat_sKv is an IO expression? Then it is actually a function in a way > (taking the "State token" as an argument). So the above applies. This is "IO" but not GHC's IO, just another type with an opaque definition and a Monad instance. There's no reason for GHC to think that sat_sKv would be a function. Of course, sat_sKw is necessarily a function since it is the second argument to bind. But only now I am noticing that even sat_sKw's definition includes *yet another* floated-out variable: sat_sKv = some complicated expression 1 sat_sKu = some complicated expression 2 sat_sKw = \_ -> sat_sKu main = bindIO sat_sKv sat_sKw Here, I don't see why GHC should think that sat_sKv and sat_sKu are functions. For example, here's the definition of sat_sKu: sat_sKu :: IO () [LclId] sat_sKu = let { sat_sRy [Occ=Once1] :: String [LclId] sat_sRy = let { sat_sRx [Occ=Once1] :: String [LclId] sat_sRx = unpackCStringUtf8# "\n"# } in let { sat_sRw [Occ=Once1] :: String [LclId] sat_sRw = case foobar True of { False -> unpackCStringUtf8# "False"#; True -> unpackCStringUtf8# "True"# } } in sApp# sat_sRw sat_sRx } in putStrOut sat_sRy Here, putStrOut is so opaque that it doesn't even have a definition, it is merely a name registered into GHC's name tables. So I really don't see why this looks "function-y" to GHC. The reason this is all a problem for me is because I would like to then interpret all these let-bindings, including the toplevel ones, as eagerly defined variables. But then there is of course a difference between main = let a1 = someIOAction1 a2 = someOtherIOAction2 a2' = \_ -> a2 in bindIO a1 a2' and main = let a1 = someIOAction1 a2 = \_ -> someIOAction2 in bindIO a1 a2 because if the *definition* of "a2" throws (not its action), then the first version will throw immediately whereas the second will only throw when "main" is *run*, after running "a1". > * I think this is the FloatOut pass. You can turn it out using > -fno-full-laziness. Not sure if some others passes might > do similar things, though. I tried turning off Opt_FullLaziness, but unfortunately I am still getting the same result. I was also hopeful when I saw there's an Opt_FloatIn flag, but alas that doesn't change this behaviour either (and it's turned on by default anyway...) I'll try to make a self-contained minimal example next week. Thanks, Gergo -----Original Message----- From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Joachim Breitner Sent: Wednesday, December 29, 2021 8:39 PM To: ghc-devs(a)haskell.org Subject: [External] Re: What's the benefit of taking "do" blocks apart? Is there a way to turn that off? [You don't often get email from mail(a)joachim-breitner.de. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.] ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients. Hi Gergo, Am Dienstag, dem 28.12.2021 um 15:57 +0000 schrieb Erdi, Gergo via ghc- devs: > PUBLIC phew > I’m seeing ‘do’ blocks getting taking apart into top-level > definitions, so e.g. > > main = do > some complicated expression 1 > some complicated expression 2 > > is compiled into > > sat_sKv = some complicated expression 1 sat_sKw = \_ -> some > complicated expression 2 main = bindIO sat_sKv sat_sKw > > This seems to happen regardless of any common subexpressions, i.e. it > is not the case that sat_sKv or sat_sKw are used anywhere else. > > What is the intended benefit of this floating-out? Is there a > particular Core-to-Core pass that causes this? Is it possible to turn > it off? didn’t investigate deeper (maybe if you provide a small example I would), but just from looking at this: * It is generally preferable to turn local lambda expressions into top-level functions. This way, instead of dynamically allocating a FUN heap object, it’s just a static function. * sat_sKv is an IO expression? Then it is actually a function in a way (taking the “State token” as an argument). So the above applies. * I think this is the FloatOut pass. You can turn it out using -fno-full-laziness. Not sure if some others passes might do similar things, though. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de https://clicktime.symantec.com/33oTTj3Bye1kkqsmxZWi3QZ6xU?u=http%3A%2F%2Fww… _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org https://clicktime.symantec.com/3bo4KFUFPcVSdMe4B1CUzr6xU?u=http%3A%2F%2Fmai… This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

2 2