Proposal: Treat OtherLetter as lower case in the grammar
_______________________________________________ Haskell-prime mailing list Haskell-prime@... http://www.haskell.org/mailman/listinfo/haskell-prime
_______________________________________________ Haskell-prime mailing list Haskell-prime@... http://www.haskell.org/mailman/listinfo/haskell-prime
Hello Haskell-Prime, I just discovered that the Haskell 2010 report allows the precedence of infix declarations to be an integer instead of just a digit. Therefore, also the following declarations are allowed: -- compiles infix 0x7 <$> infix 0o7 <$> -- does not compile because of precedence out of range infix 0xa <$> infix 0oa <$> infix 123 <$> Interestingly, the in section 4.4.2 (Fixity Declarations) the report says: > The *integer* in a fixity declaration must be in the range 0 to 9. as well as > If the *digit* is omitted, level 9 is assumed. This is of course no problem, I'm just curious if there is some motivation for integer I'm not aware of. Kind Regards, Björn _______________________________________________ Haskell-prime mailing list Haskell-prime <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Cross-post to haskell-prime in case there's any interest for including this into the report's FFI specification. Proposal - Foreign enum support =============================== At the moment the FFI does not have a convenient way with interacting enums (whether proper enums or CPP defines) in C (like languages). Both enums and CPP defined enums are major parts of large C APIs and they are thus crucial to writing foreign bindings. A few examples: SDL_image defines the following enum: typedef enum { IMG_INIT_JPG = 0x00000001, IMG_INIT_PNG = 0x00000002, IMG_INIT_TIF = 0x00000004, IMG_INIT_WEBP = 0x00000008 } IMG_InitFlags; OpenCL specifies the following typedefs + CPP defined enum: typedef uint32_t cl_uint __attribute__((aligned(4))); typedef cl_uint cl_platform_info; /* cl_platform_info */ #define CL_PLATFORM_PROFILE 0x0900 #define CL_PLATFORM_VERSION 0x0901 #define CL_PLATFORM_NAME 0x0902 #define CL_PLATFORM_VENDOR 0x0903 #define CL_PLATFORM_EXTENSIONS 0x0904 OpenCL functions will return the above CPP defines as return values of type cl_platform_info. Current Solutions ----------------- In many cases someone wrapping such a C library would like to expose these enums as a simple sum type as this has several benefits: type safety, the ability to use haskell constructors for pattern matching, exhaustiveness checks. Currently the GHC FFI, as specified by Haskell2010, only marshalls a small set of foreign types and newtypes with exposed constructors of these types. As such there seem two approaches to wrap these enums: 1. Implement an ADT representing the enum and write a manual conversion function between the ADT and the corresponding C type (e.g. CInt -> Foo and Foo -> CInt). 2. Use a tool like c2hs to automatically generate the ADT and conversion function. In both cases the foreign functions are imported using the corresponding C type in their signature (reducing type safety) and the user is forced write trivial wrappers for every imported function to convert the ADT to the relevant C type and back. This is both tedious to write and costly in terms of code produced, in case of c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for every argument/result even though this could trivially be a no-op. Worse, since c2hs uses the Enum class for it's conversion to/from C types it generates Enum instances like: instance Enum Foo where fromEnum Bar = 1 fromEnum Baz = 1337 toEnum 1 = Bar toEnum 1337 = Baz toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ show unmatched) Since succ/pred and enumFromTo's default implementations assume enums convert to continuous sequence of Int this means the default generated enum instances crash. This problem could be overcome by making c2hs' code generation smarter, but this does not eliminate the tediousness of wrapping all foreign imported functions with marshalling wrappers, NOR does it eliminate the overhead of all this useless marshalling. Proposal -------- Add a new foreign construct for enums, the syntax I propose below is rather ugly and ambiguous and thereforeopen to bikeshedding, but I prefer explaining based on a concrete example. foreign enum CInt as Foo where Bar = 1 Baz Quux = 1337 Xyzzy = _ This would introduce a new type 'Foo' with semantics approximately equivalent too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo 1; pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _". Explicit listing of the value corresponding to a constructor should be optional, missing values should just increment by one from the previous (like C), if the initial value is missing, it should assume to start from 0. Values do not need to be contiguous. Users should be able to use these constructors as normal in pattern match (really, this mostly follows to semantics of the above pattern synonyms). The foreign import/export functionality should invisibly marshall Foo to the underlying foreign type (as is done for newtypes). I'm unsure about the support for a wildcard constructor like Xyzzy. If there is support for a wildcard, it should be optional. On the upside a wildcard means the marshalling is no longer a partial function. The downside is that it makes desugaring the use of enums in patterns harder. It seems clear that f Xyzzy = {- ... -} f Bar = {- ... -} f Baz = {- ... -} f Quux = {- ... -} Should not have the same semantics as: f (Foo _) = {- ... -} f (Foo 1) = {- ... -} f (Foo 2) = {- ... -} f (Foo 1337) = {- ... -} So in the presence of wildcards, the Foo enum can't trivially be desugared into pattern synonyms after checking exhaustiveness. Pros: 1. Foreign imports are slightly more type safe, as one can now write: foreign import ccall "someFoo.h" someFoo :: Foo -> Ptr () -> IO () Preventing users from passing an arbitrary CInt to an argument expecting a specific enum. 2. No need to write marshalling functions to/from ADT to obtain exhaustiveness checks and pattern matching 3. Cheaper as marshalling Foo to CInt is a no-op 4. toEnum/fromEnum can simply map to contiguous sequence of Int as this Int mapping is no longer used for marshalling Cons: 1. Non-standard extension of the FFI 2. Someone has to implement it 3. Wildcards constructors would present difficulties desugaring pattern matches to a simple newtype. 4. ?? What Would Need to be Done? --------------------------- 1. Parser needs to be extended to deal with parsing of enum declarations. 2. Pattern matches of an enum type need to be checked for exhaustiveness and desugared to the underlying type's representation. 3. Extend foreign imports/exports to marshall enums properly. If there's no objections I'm willing to take a stab at implementing this, although I'd probably need some help with GHC's internals (although I could bug #ghc for that). Cheers, Merijn
_______________________________________________ Haskell-prime mailing list Haskell-prime@... http://www.haskell.org/mailman/listinfo/haskell-prime
L.S., I am trying to register as a user in the Haskell prime trac, but I get the error message: --------------------------- Oops… Trac detected an internal error: IOError: [Errno 2] No such file or directory: '' There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue. To that end, you could a ticket. The action that triggered the error was: POST: /register TracGuide — The Trac User and Administration Guide --------------------------- I tried to register with the browsers Opera, FireFox and Internet Explorer; each gave the same message. Regards, Henk-Jan van Tuyl -- -- Folding <at> home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- _______________________________________________ Haskell-prime mailing list Haskell-prime <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Hello *, I'd like to point your attention to https://ghc.haskell.org/trac/ghc/ticket/8695 which brings up the issue what the results operations such as * `div minBound (-1)` * `quot minBound (-1)` * `abs minBound` shall result in for the standard H2010 fixed-width signed types such as `Int`, that is whether ⊥ (arithmetic overflow-exception) or `minBound` is the more appropriate result. Relevant sections from the Haskell 2010 report: (http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1350006.4) | 6.4. Numbers | | [...] The results of exceptional conditions (such as overflow or | underflow) on the fixed-precision numeric types are undefined; an | implementation may choose error (⊥, semantically), a truncated value, | or a special value such as infinity, indefinite, etc. ...which seems contradictory to... (http://www.haskell.org/onlinereport/haskell2010/haskellch18.html#x26-22400018.1) | * 18.1. Signed integer types | | This module provides signed integer types of unspecified width (Int) | and fixed widths (Int8, Int16, Int32 and Int64). All arithmetic is | performed modulo 2^n, where n is the number of bits in the type. | [...] Would a Haskell 2010 implementation which turns *every* integer over/underflow (even those for addition or multiplication of 'Int' values whose result would lie outside of [minBound..maxBound]) into a arithmetic exception be a valid H2010 implementation? -- hvr _______________________________________________ Haskell-prime mailing list Haskell-prime <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
_______________________________________________ Haskell-prime mailing list Haskell-prime@... http://www.haskell.org/mailman/listinfo/haskell-prime
Module System.Posix.Directory of the unix package defines getWorkingDirectory :: IO FilePath changeWorkingDirectory :: FilePath -> IO () I believe the functionality is quite portable and not limited to unix-like systems. I know that e.g. Windows has chdir and getcwd. Module Filesystem of the system-fileio package has getWorkingDirectory :: IO FilePath setWorkingDirectory :: FilePath -> IO () I propose to add these functions to System.Environmant or maybe System.Directory. Rationale: (1) This is standard functionality that should at least be in the Haskell Platform, if not in the standard libraries. (2) I would like to avoid depending on an extra package just to have these two very basic functions available in a OS independent way. (3) "system-fileio".Filesystem does not seem to be the right place for this. The last point may be arguable, but the first two are plain common sense IMO. Cheers Ben -- -- "Make it so they have to reboot after every typo." ? Scott Adams
Lista de emails trabalho com mala direta mala direta como fazer lista de mail também lista de emails, cadastro email lista email: http://www.maladiretaemails.com Nós sabemos que list mail, é muito legal para a maioria das pessoas. endereco de email listas email e acima de tudo lista de emails, email de empresas o que e mailing, o objetivo de nosso website. se você busca emails de pessoas, email marketing e também email mailing: http://www.maladiretaemails.com é excelente listas de emails tais como lista email, endereco de email lista com emails. é fantástico emails de pessoas e, além disso lista email. envio de emails email cadastro, marketing email. atualmente lista de email compreendendo Enviar email, newsletter pode ser bastante bom. é realmente a função do nosso website: cadastro email, Enviar email, e bem como listas de emails. Oferecemos o melhor em lista de email listas de emails, envio de emails.
The current record system is notorious for three major flaws:
It does not solve the namespacing problem. I.e., you cannot have two records sharing field names in a single module. E.g., the following won't compile:
It's partial. The following code will result in a runtime error:
It does not allow you to use the same field name for different types across constructors:
This proposal approaches all the problems above and also a fourth one, which is unrelated to the current record system: it allows one to avoid declaration of intermediate types (see details below).
Gentlemen, I want you to meet,
When a record-syntax is used in Haskell it's almost always a single-constructor ADT. A question rises then: why use ADT when you don't need its main feature (i.e., the multiple constructors)? This main feature is actually the root of the second and the third problem of record-syntax from the list above. In such situations one doesn't actually need ADT, but something more like a tuple with ability to access its items by name. E.g.:
application:
So now you think "Okay, but how about naming it?". Well, not a problem at all - use the existingtype-construct:
Now, about the avoidance of intermediate types:
See? No need to declare separate types for inner values. But, of course, if you need, you still can:
We can nicely access the deeply nested fields, e.g.:
Okay. What about the type ambiguity? E.g., in the following the Person is actually the same type asCompany:
Easily solvable with a help of newtype:
What about ADTs? Again, easy:
Now, the beautiful fact:
This solution does not conflict with any existing feature of Haskell! As the examples show, it easily fits into the language as an extension. It can peacefully coexist with the existing record system of ADTs. Hence a complete backwards compatibility with old codebase. There's also a potential for many other additional features.
_______________________________________________ Haskell-prime mailing list Haskell-prime@... http://www.haskell.org/mailman/listinfo/haskell-prime
Proposal: add a non-recursive let to the Haskell language. In let' p = e in e' do { ... let' p = e ... } the variables of pattern p are then *not* in scope in e. Reasons for adding a non-recursive let: 1. recursive-let is the source for many non-termination bugs. An instance of such a bug is in the state monad of mtl-2.1 (forgive me, Edward, for quoting this again): http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#state state :: (s -> (a, s)) -> m a state f = do s <- get let ~(a, s) = f s put s return a here, a non-recursive let was meant, the s bound by the let was supposed to be a new state, shadowing the old state. However, since let is recursive, this actually causes a loop. Another instance (cut-down) are let-guards like let Just x | x > 0 = e in x The "x > 0" is understood as an assertion here, documenting an invariant. However, Haskell reads this as let Just x = case () of { () | x > 0 -> e } in x leading to non-termination. A non-recursive version let' Just x | x > 0 = e in x could be interpreted as case e of { Just x | x > 0 -> x } instead, which is meaningful (in contrast to the current interpretation). 2. Connected to 1., a non-recursive let allows for painless shadowing. For instance, the hack do ... x <- return $ f x exploiting non-recursiveness of the <- binding, would be unnecessary, instead we could write do ... let' x = f x NB: In a do-Block, we could drop the keyword let' and simply write do ... x = f x for a non-monadic binding, in accordance to x <- mf x, See also http://www.haskell.org/pipermail/beginners/2009-February/001075.html http://stackoverflow.com/questions/8398607/declaration-order-in-let-bindings-haskell-vs-ocaml PS.: I can work out the details of grammar and semantics if this proposal finds followers. Cheers, Andreas -- -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@... http://www2.tcs.ifi.lmu.de/~abel/
This is fairly the same as http://hackage.haskell.org/trac/ghc/ticket/8021 but it's rewritten a little Interfaces Interface is a generalization of the class. Now class become just *instances* of interface For backward compatibility compiler should calculate interface by itself, but it should allow to write interfaces to everybody (more detail at "Maybe Problems"). /-- it is calculated by the Compiler or is written directly/ class interface Monoid (a :: k) where /-- like Typeable/ mempty :: * mappend :: * -> * -> * class Monoid a where ... class Monad m => Monoid m where ... class Arrow c => Monoid c where ... It is easy to use them with functions: foo :: (Monad m => Monoid m , Monad m ) => m a bar :: (Arrow c => Monoid c, Arrow c) => c b a These classes are open, you could lately add class MyClass c => Monoid c where ... We use like Typeable (a :: k) because: () => Monoid a :: * Monad m => Monoid m :: * -> * Arrow c => Monoid c :: * -> * -> * Backward compatibility If class have single constraint, you could write without it. If class have many constraints, you could write without it, if it is empty one. bar :: MonadPlus m => m a <<==>> bar :: () => Monad m => MonadPlus m => m a foo :: Monoid a => a <<==>> foo :: () => Monoid a => a baz :: Monad m => Monoid m => m a <<==>> baz :: () => Monad m => Monoid m => m a Better than superclasses we already have class Num a where ... But we wish to generalize it. It's easy now, we just add: class Additive a where addplus = ... class Multiplicative a where multprod = ... class (Additive a, Multiplicative a) => Num a where (+) = addplus (*) = multprod foo :: (Additive a, Multiplicative a) => Num a => a -> a -> a Maybe Problems 1) If we have already class class Foo a where data F :: ... type S :: ... data family G ... what interface do we have ? Possible reply - no data in the interface. 2) What is the interface of Typeable ? 2.1) What is the interface of class with unwritten interface? Possible reply - the same as class, so it is easy to Compiler. 3) Misfeature - to allow write interface manually Why? You can't change it later. So, it must be deprecated from the beginning. -- View this message in context: http://haskell.1045720.n5.nabble.com/Interfaces-the-Golden-Path-of-Haskell-tp5732208.html Sent from the Haskell - Haskell-prime mailing list archive at Nabble.com.
Mon | Tue | Wed | Thu | Fri | Sat | Sun |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
5 | |
---|---|
3 | |
1 | |
4 | |
4 | |
1 | |
9 | |
2 | |
13 | |
22 | |
43 | |
11 | |
1 | |
21 | |
1 | |
21 | |
22 | |
18 | |
2 | |
10 | |
14 | |
7 | |
8 | |
4 | |
132 | |
35 | |
3 | |
1 | |
12 | |
4 | |
8 | |
65 | |
20 | |
34 | |
19 | |
38 | |
5 | |
25 | |
1 | |
16 | |
2 | |
61 | |
8 | |
29 | |
15 | |
7 | |
74 | |
4 | |
7 | |
19 | |
18 | |
22 | |
55 | |
147 | |
23 | |
2 | |
52 | |
8 | |
22 | |
4 | |
11 | |
12 | |
2 | |
24 | |
1 | |
11 | |
37 | |
224 | |
48 | |
10 | |
5 | |
12 | |
6 | |
11 | |
32 | |
23 | |
40 | |
16 | |
41 | |
85 | |
69 | |
43 | |
113 | |
129 | |
56 | |
67 | |
12 | |
69 | |
304 | |
371 | |
598 | |
218 |