- ghc-devs - Haskell.org

RE: Alex install failure
by Simon Peyton Jones 28 Aug '17

28 Aug '17

| note that you mistyped "lockd" (aka "lock daemon") as "locd" Oh, sorry about mistyping simonpj@cam-05-unx:~/tmp$ ps -Af | grep lockd root 140 2 0 2016 ? 00:00:00 [kblockd] simonpj 7882 1184 0 13:22 pts/7 00:00:00 grep lockd | also, the output of "rpcinfo -p" would be interesting to know simonpj@cam-05-unx:~/tmp$ rpcinfo -p Command 'rpcinfo' is available in '/usr/sbin/rpcinfo' The command could not be located because '/usr/sbin' is not included in the PATH environment variable. This is most likely caused by the lack of administrative privileges associated with your user account. rpcinfo: command not found | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 28 August 2017 12:51 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Alex install failure | | Simon, | | note that you mistyped "lockd" (aka "lock daemon") as "locd" | | also, the output of "rpcinfo -p" would be interesting to know | | On Mon, Aug 28, 2017 at 1:47 PM, Simon Peyton Jones via ghc-devs <ghc- | devs(a)haskell.org> wrote: | > | Hmm, alright then. What do the following say, | > | | > | * ps -Af | grep lockd | > | * ps -Af | grep portmap | > | * ps -Af | grep rpcbind | > | * mount | grep nfs | > | | > | > simonpj@cam-05-unx:~/tmp$ ps -Af | grep locd | > simonpj 20138 1184 0 12:46 pts/7 00:00:00 grep locd | > | > simonpj@cam-05-unx:~/tmp$ ps -Af | grep portmap | > simonpj 22601 1184 0 12:46 pts/7 00:00:00 grep portmap | > | > simonpj@cam-05-unx:~/tmp$ ps -Af | grep rpcbind | > root 1472 1 0 2016 ? 00:00:13 rpcbind -w | > simonpj 26634 1184 0 12:46 pts/7 00:00:00 grep rpcbind | > | > simonpj@cam-05-unx:~/tmp$ mount | grep nfs camresunxa02:/home on /home | > type nfs (rw,intr,vers=4,addr=10.190.50.19,clientaddr=10.190.108.81) | > | > | -----Original Message----- | > | From: Ben Gamari [mailto:ben@well-typed.com] | > | Sent: 25 August 2017 17:46 | > | To: Simon Peyton Jones <simonpj(a)microsoft.com> | > | Cc: ghc-devs <ghc-devs(a)haskell.org> | > | Subject: RE: Alex install failure | > | | > | Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: | > | | > | > | I have implemented this in wip/ghc-pkg-locking. Do you think | > | you > | could give this branch a try? If it still fails then we'll | > | have to > | try to debug things in-situ. | > | > | > | > Alas, no go. | > | > | > | Hmm, alright then. What do the following say, | > | | > | * ps -Af | grep lockd | > | * ps -Af | grep portmap | > | * ps -Af | grep rpcbind | > | * mount | grep nfs | > | | > | Cheers, | > | | > | - Ben | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csi | > monpj%40microsoft.com%7C33b163bdb97f4f59d80f08d4ee0b07ea%7C72f988bf86f | > 141af91ab2d7cd011db47%7C1%7C0%7C636395178517098924&sdata=EOVdQbvvTDGP9 | > 2o8AHcVEcapHMicnVptxMCpwRPrsvE%3D&reserved=0

3 5

Alex install failure
by Simon Peyton Jones 28 Aug '17

28 Aug '17

Friends I'm trying to update my installation of alex, on Unix (Ubuntu). But I get the dump below It's complaining about a lock file being an invalid argument (see highlight below). If I manually remove the file I get past that, it successfully installs tf-random, but the same thing happens on the next package. So I can install packages one at a time, but that's silly. Any ideas? Simon cabal install alex Resolving dependencies... Configuring tf-random-0.5... Building tf-random-0.5... Failed to install tf-random-0.5 Build log ( /home/simonpj/.cabal/logs/tf-random-0.5.log ): cabal: Entering directory '/tcabal mp/cabal-tmp-26141/tf-random-0.5' Configuring tf-random-0.5... Building tf-random-0.5... Preprocessing library tf-random-0.5... [1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs, dist/build/System/Random/TF/Gen.o ) [2 of 4] Compiling System.Random.TF.Init ( src/System/Random/TF/Init.hs, dist/build/System/Random/TF/Init.o ) src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations] In the use of 'bitSize' (imported from Data.Bits): Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead" | 94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 not implemented" | ^^^^^^^ [3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs, dist/build/System/Random/TF.o ) [4 of 4] Compiling System.Random.TF.Instances ( src/System/Random/TF/Instances.hs, dist/build/System/Random/TF/Instances.o ) Creating package registration file: /tmp/pkgConf-tf-random-05965166491189641421.5 Installing library in /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.2.1/tf-random-0.5-ABDhxe3mXYlHUEE5hzgewx Registering tf-random-0.5... cabal: '/usr/local/bin/ghc-pkg' exited with an error: ghc-pkg: Couldn't open database /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d for modification: {handle: /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) cabal: Leaving directory '/tmp/cabal-tmp-26141/tf-random-0.5' cabal: Error: some packages failed to install: QuickCheck-2.10.0.1 depends on tf-random-0.5 which failed to install. alex-3.2.1 depends on tf-random-0.5 which failed to install. tf-random-0.5 failed during the final install step. The exception was: ExitFailure 1 simonpj@cam-05-unx:~/code/HEAD$

5 11

Re: New primitive types?
by David Feuer 27 Aug '17

27 Aug '17

Atomic operations, or the lack thereof, don't seem terribly relevant to immutable Haskell constructor fields. David FeuerWell-Typed, LLP -------- Original message --------From: Carter Schonwald <carter.schonwald(a)gmail.com> Date: 8/26/17 10:56 PM (GMT-05:00) To: Florian Weimer <fw(a)deneb.enyo.de>, Michal Terepeta <michal.terepeta(a)gmail.com> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: Re: New primitive types? Which architectures are which? I assume you mean the dec alpha allowed atomic operations on bytes... but your phrasing is a teeny bit unclear On Sat, Aug 19, 2017 at 4:34 AM Florian Weimer <fw(a)deneb.enyo.de> wrote: > * Michal Terepeta: > > > On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald < > carter.schonwald(a)gmail.com> > > wrote: > >> One issue with packed fields is that on many architectures you can't > > quite do subword reads or > >> writes. So it might not always be a win. > > > > Could you give any examples? > > Historic DEC Alpha, now long obsolete. > > It is very hard to create compliant and performant implementations of > Java 5, C 11 or C++ 11 on such architectures. All these languages > (and their subsequent revisions) require that naturally aligned > objects can be accessed independently. For example, you can't use a > simple read-modify-write cycle to implement a single-byte store using > word operations. > > That's why such architectures really do not have a future (or even a > present), except maybe in niche markets such as GPGPU (but even there, > things are heading towards the de-facto standard memory model). >

1 0

Tying knots with strict constructors
by David Feuer 27 Aug '17

27 Aug '17

Once in a while, one desires to tie a recursive knot and is stymied by a strict data constructor. I recently encountered this problem trying to improve the implementation of `never` in the `streaming` package. The Stream type is defined thus: data Stream f m r = Step !(f (Stream f m r)) | Effect (m (Stream f m r)) | Return r It would be nice to be able to write never :: Applicative f => Stream f m r never = fix (Step . pure) Unfortunately, if `pure` is strict (e.g., Identity), this won't work. The Step wrapper attempts to force `pure never` and then apply the Step worker. This will never work. The streaming package works around the problem by representing the `never` stream in a different way, at the potential cost of some efficiency. In other contexts, there may be no (safe) workaround at all. This is terribly frustrating, because it seems almost possible to express what I want in Core, and even possible to express it in Haskell with a really awful unsafeCoerce. The nasty version looks like this: data StreamL f m r = StepL (f (StreamL f m r)) | EffectL (m (StreamL f m r)) | ReturnL r never :: forall f m r. Applicative f => Stream f m r never = case loop of StepL x -> x `pseq` unsafeCoerce loop where loop :: StreamL f m r loop = StepL (pure loop) in loop {-# NOINLINE loop #-} {-# NOINLINE never #-} That is, I make a copy of the Stream type, but with a lazy version of the Step constructor, I tie my knot, I make very sure that the strict field is evaluated, and then I unsafeCoerce the whole thing in a thoroughly unsupported fashion to get back to the right type. Ideally, It would be nice to get GHC to manufacture, and expose to users, bidirectional patterns that offer more access to the raw representation of a type. Basically, I want to get a bidirectional pattern for Step that: 1. Is lazy when used as a constructor (applying the "worker" constructor directly) 2. Is viewed as lazy on matching, so the strictness analysis comes out right. Using such a feature will presumably always be dangerous (unless someone does a ton of work to find an efficient way to make it safe), but I'd rather have a reasonable dangerous way to do it than an unreasonable dangerous way, if that can be accomplished. Unfortunately, I haven't been able to think of a reasonable design for such a language feature. Does anyone else have any ideas? Or some other thought about how such things might be done? David

1 0

Where to raise an issue for the stm library
by Harendra Kumar 26 Aug '17

26 Aug '17

Can someone tell me where to raise an issue for the stm library? The hackage link sends me here http://git.haskell.org/packages/stm.git. But this page provides no clue on raising issues. I wondered if GHC trac itself is used for this library. I saw some other libraries in the drop down list but not this one in the GHC trac ticket creation page. It is frustrating that figuring out how to raise an issue is not easy for such an important library. -harendra

3 5

Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs
by Shayan Najd 25 Aug '17

25 Aug '17

In this thread, I am going to raise a topic for discussion. Please share your opinions and related experiences. Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a fixed phase index, such as `GhcPs`, gives us distinct ASTs at the *compile-time*. However, when programming with these ASTs, we use patterns, such as `HsMultiIf :: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared among phases. We can (1) introduce a layer of abstraction providing a set of type and pattern synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS LPsExpr] -> PsExpr`; and (2) updating code working on ASTs of specific phase to use the interface specific to the phase, such as by changing prefixes from `Hs` to `Ps` and by removing unused variables and placeholders; and (3) leaving untouched code working uniformly on ASTs of different phases (i.e., the generic functions in Trees that Grow terminology), such as the existing functions whose types are polymorphic on phase index. Some comments: - It can be done gradually and smoothly: we add three separate files in HsSyn (per each phase) containing the phase-specific interfaces, and gradually import them and do the changes per module. - Using the interfaces is optional: code using the current method (e.g., using `HsMultiIf`) should work just fine. - It introduces a layer of indirection and three more files to maintain. - It makes code working on HsSyn ASTs, such as the renamer, appear cleaner as placeholders and similar machinery are abstracted away by the interfaces (e.g., no need to import bits and pieces of `HsExtension`) - In theory, there should be zero impact on GHC's runtime performance. I am myself undecided about its benefit-cost ratio, but willing to at least implement the phase-specific interfaces. For me, abstracting away all the `PostRn` stuff, `Out` prefixed constructors, and dummy placeholders from the front-end code is the most valuable. Yours, Shayan

2 3

Stg-lint and bootstrapping (fails?)
by Gabor Greif 24 Aug '17

24 Aug '17

Hi all, I tried an stg-lint build thus: $ make V=1 GhcStage2HcOpts="-O1 -g -dstg-lint" ... and failed: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.10.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id rts -package-id ghc-prim-0.5.1.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -dcore-lint -dno-debug-output -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./System/Mem/Weak.hs -o libraries/base/dist-install/build/System/Mem/Weak.o -dyno libraries/base/dist-install/build/System/Mem/Weak.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.10.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id rts -package-id ghc-prim-0.5.1.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -dcore-lint -dno-debug-output -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./Control/Monad/IO/Class.hs -o libraries/base/dist-install/build/Control/Monad/IO/Class.o -dyno libraries/base/dist-install/build/Control/Monad/IO/Class.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O1 -g -dstg-lint -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/utils/Exception.hs -o compiler/stage2/build/Exception.o -dyno compiler/stage2/build/Exception.dyn_o /home/ggreif/%NoBackup%/ghc-head/libraries/base/dist-install/build/GHC/IO/Exception.hi Declaration for $fExceptionIOException4 Unfolding of $fExceptionIOException4: Failed to load interface for ?GHC.Fingerprint? There are files missing in the ?base-4.10.0.0? package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): kindPrimRep * -> * typePrimRep (m_as6 :: * -> *) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:344:5 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:305:18 in ghc:RepType typePrimRep, called at compiler/stgSyn/StgLint.hs:437:17 in ghc:StgLint Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <<ghc: 144952288 bytes, 38 GCs, 4093040/9445544 avg/max bytes residency (4 samples), 61M in use, 0.000 INIT (0.000 elapsed), 0.355 MUT (0.386 elapsed), 0.216 GC (0.216 elapsed) :ghc>> make[1]: *** [compiler/stage2/build/Exception.o] Error 1 make: *** [all] Error 2 What is the status of stg-lint? Is the above expected to happen? This is stock `master` branch as of today. Cheers, Gabor

3 10

Docs
by Simon Peyton Jones 22 Aug '17

22 Aug '17

Ben et al I’m getting this on Linux when making documentation. I have not modified any of this documentation. Any ideas? Simon reading sources... [ 97%] what_glasgow_exts_does reading sources... [100%] win32-dlls reading sources... [ 97%] what_glasgow_exts_does reading sources... [100%] win32-dlls /5playpen/simonpj/HEAD-1/docs/users_guide/editing-guide.rst:398: ERROR: Error in "ghci-cmd" directive: invalid option block. .. ghci-cmd:: :module; [*]⟨file⟩ :noindex: Load a module /5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:496: ERROR: Error in "ghci-cmd" directive: invalid option block. .. ghci-cmd:: :{ :} Begin or end a multi-line GHCi command block. /5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:527: ERROR: Error in "warning" directive: invalid option block. .. warning:: Temporary bindings introduced at the prompt only last until the next :ghci-cmd:`:load` or :ghci-cmd:`:reload` command, at which time they will be simply lost. However, they do survive a change of context with :ghci-cmd:`:module`: the temporary bindings just move to the new location. /5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:533: ERROR: Error in "hint" directive: invalid option block.

2 2

Re: Alex install failure
by Ara Adkins 19 Aug '17

19 Aug '17

NFS can be pretty dodgy with transient files due to latency. Sometimes the delete takes appreciable time after the command is issued so the lock file might just be persisting. I’d try installing into a cabal sandbox on a local drive and see if the same issue crops up. _ara > On 18 Aug 2017, at 23:43, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. So what? > > Simon > > | -----Original Message----- > | From: Ben Gamari [mailto:ben@smart-cactus.org] > | Sent: 18 August 2017 13:05 > | To: Simon Peyton Jones <simonpj(a)microsoft.com>; ghc-devs <ghc- > | devs(a)haskell.org> > | Subject: Re: Alex install failure > | > | Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: > | > | > Friends > | > I'm trying to update my installation of alex, on Unix (Ubuntu). But I > | > get the dump below It's complaining about a lock file being an invalid > | argument (see highlight below). > | > If I manually remove the file I get past that, it successfully > | > installs tf-random, but the same thing happens on the next package. So > | > I can install packages one at a time, but that's silly. > | > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > | > | Cheers, > | > | - Ben > >

2 2

Re: Where to discuss the linear types extension of GHC?
by Boespflug, Mathieu 18 Aug '17

18 Aug '17

Hi Wolfgang, great to see interest in linear types! I would advise caution about building anything on top of the linear types extension at this time. If you have interesting use cases, however, do tell, so that these use cases can influence the design. This is pre-alpha software, meaning that it's not even good enough as a developer preview of all the basic features. It's an in-progress development branch, which is going to take time to stabilize. Furthermore, whether the feature makes it into GHC will depend on what the GHC proposals committee thinks about it. The current authors of the would-be extension have yet to draft a proposal and submit it to the committee. If we manage to write a proposal in time, based on a beta level implementation of linear types, and if the committee accepts the proposal, then maybe the feature can make it into GHC 8.4. Or in GHC 8.6. That's our hope, at any rate. But it could also be never, if the committee rejects the proposal... Best, -- Mathieu Boespflug Founder at http://tweag.io. On 18 August 2017 at 22:55, Wolfgang Jeltsch <wolfgang-it(a)jeltsch.info> wrote: > Hi! > > I just read through the README. According to it, there are several crucial > things not implemented yet (case and let come to my mind), and there are > some fundamental bugs (which make it very easy to circumvent linearity > checks, making the whole extension pointless). Is the situation still like > this? > > What are your honest expectations regarding the future development of the > linear types feature and its integration into the official GHC? Is it > realistic to hope for this feature to be available in a stable GHC version > withing, say, the next 12 months? I would like to use linearity in some > project of mine, but at the moment, I am unsure whether it is really a good > idea to rely on this feature becoming available. > > All the best, > Wolfgang > > Am Mittwoch, den 19.07.2017, 08:52 +0000 schrieb Edvard Hübinette: > > Hi Wolfgang, > > the updated README is live and can be found here > <https://github.com/tweag/ghc/tree/linear-types>! > > Cheers, > Edvard > > On Thu, 13 Jul 2017 at 17:54 Spiwack, Arnaud <arnaud.spiwack(a)tweag.io> > wrote: > > I think the answer to both questions can be the same: the github issue of > Tweag's ghc repo: https://github.com/tweag/ghc/issues . > > Regarding this particular bug: it is a known bug indeed. I'll be fixing it > soon. We're expanding the README to include known bugs and usage > instruction. > > Thanks a lot for your time and interest, > Arnaud > > On Thu, Jul 13, 2017 at 12:14 AM, Wolfgang Jeltsch < > wolfgang-it(a)jeltsch.info> wrote: > > Hi! > > Another question is where to submit bugs. I already found the first one 😉: > > GHCi> let dup :: a -> (a, a); dup x = (x, x) > > GHCi> let unsafeDup :: a ⊸ (a, a); unsafeDup = dup > > GHCi> :type unsafeDup > > unsafeDup :: a ⊸ (a, a) > > GHCi> unsafeDup True > > (True,True) > > > All the best, > Wolfgang > > Am Mittwoch, den 12.07.2017, 23:15 +0300 schrieb Wolfgang Jeltsch: > > Hi! > > I think I will have several questions about the linear types extension > when trying to use it in the near future. Furthermore, I also want to give > feedback on the design of this extension. What is the appropriate forum for > discussing the linear types extension? The GHC developers mailing list > might be an option. However, I think that it would be better to contact you > more directly regarding these matters. Is there some issue tracker or > discussion platform I should use? > > All the best, > Wolfgang > > > > >

2 1