Re: [Haskell-cafe] Haddock GSOC project progress
On 31/07/13 06:37, Roman Cheplyaka wrote: Hi Mateusz, This looks great — I'm especially excited about List entries no longer have to be separated by empty lines! Glad to hear that. However, the decision to use Attoparsec (instead of Parsec, say) strikes me as a bit odd, Parsec has a dependency on Data.Text that you can't easily get rid of. With Attoparsec, I was able to simply get rid of the modules I was not interested in (anything with Text) and only keep the ByteString part. as it wasn't intended for parsing source code. We're not parsing source code. As I mention, we get comment content out from GHC and parse the markup there. In particular, I'm concerned with error messages this parser would produce. Currently there exist only two error messages: one for when module header parsing fails and another one for when parsing of anything else fails. Currently the parsing functions have the type ‘DynFlags - String - Maybe (Doc RdrName)’ and if we get out Nothing then you get a generic error message and no guidance. This is also the current behaviour. Now, I agree that this sounds horrible BUT in actuality, there's not much information we could ever give. This isn't the case of inability to do so: I could simply add a (| fail error message) to relevant parts and it would get propagated up. The reason why I said that this isn't much of a problem is because there are very few cases where parsing actually can fail: in most cases if your markup isn't valid semantically, it's probably valid syntactically as a regular string. I mention in my post that we will now accept a bit wider range of syntax. In the past, this: some text exampleExpression result would fail and you would get the unhelpful error messages. With the new parser this will simply be accepted as a regular string. In fact, I actually can't think of a comment that would result in parse error with the new parser. Just to check, I just ran 500 randomly generated strings using QuickCheck through each of the two parsing functions exposed to the rest of the program and none of them caused a parse error. It's up to the developer to visually inspect that their markup produced what they wanted – we can't read minds (and frankly, the rules are fairly simple). Roman * Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [2013-07-30 23:35:45+0100] Greetings cafe, As some of you might know, I'm hacking on Haddock as part of Google Summer of Code. I was recently advised to create a blog and document some of what I have been doing recently. You can find the blog at [1] if you're interested. The first post goes over the work from the last month or so. Future posts should be shorter and on more specific topics. There's an overview of what has happened/changed/will change at the bottom of the post if you're short on time. Thanks. [1] - http://fuuzetsu.co.uk/blog I would also like to take this opportunity to say that there is one more change that I forgot to mention. Obviously invalid strings between double quotes will no longer be treated as module names and blindly linked. The checking will only be on the syntax of the string so it will still create hyperlinks to syntactically valid module names that might not actually exist. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock GSOC project progress
Is Data.Text as an extra dependency really that bad? Remember that you are parsing comments, prose, human produced text, where Data.Text is way more useful than ByteString. -- Mats Rauhala MasseR ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hdbi-1.0.0 and hdbi-postgresql-1.0.0
Regard parameterized SQL: It might be worth using named parameters (e.g.
:foo and :bar or something like that) rather than ? as
placeholders in SQL/prepared SQL. This will make it slightly more
flexible if you need to provide different SQL strings for different
databases, but want to reuse the code which does the actual running of
the SQL. It's also more flexible if you need to repeat parameters -- the
latter is typical with PostgreSQL if you want to emulate
update-or-insert in a single SQL statement
Named parameters might be more flexible, but it is need to think hard about
how to implement this.
If you are using named parameters you need to pass not just list [SqlValue]
as parameters,
but Map Text SqlValue or something. So named parameters will not be
compatible with unnamed and will need
separate query parser.
Regarding migrations: If you haven't already, please have a look at
Liquibase (http://www.liquibase.org/documentation/index.html) before
attempting to implement migrations. The most important attributes of
Liquibase are:
What I am trying to implement is not a new migration system, but just the
common interface for
simple schema actions, here is my in-mind draft:
newtype TableName = TableName Text
data TableDescription = TableDescription
{tableName :: TableName
,tableFields :: [FieldDescription]
}
class (Connection con) = Introspect con where
getTableNames:: con - IO [TableName]
describeTable :: con - TableName - IO TableDescription
getIndexes :: con - [IndexDescription]
class (Connection con) = SchemaChange con where
createTable :: con - TableDescription - IO ()
dropTable :: con - TableName - IO ()
addColumn :: con - TableName - FieldDescription - IO ()
...
This typeclasses must provide database-independent schema introspection and
changing.
Migration system can be anything you want.
I also have the idea do not throw the exceptions in IO but return (Either
SqlError a) from
all the Connection and Statement methods for safe data processing. What do
you think about ?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock GSOC project progress
On 31/07/13 08:21, Mats Rauhala wrote: Is Data.Text as an extra dependency really that bad? Remember that you are parsing comments, prose, human produced text, where Data.Text is way more useful than ByteString. It has to come with GHC boot packages and it currently doesn't. I have updated my post accordingly to mention it. ByteString indeed has its problems (I have to be quite careful to make sure unicode doesn't get mangled) but that's just how it is at the moment. If Text ever makes it in, the transition will be trivial. We're not doing anything fancy to the text we get out anyway so any performance difference it might bring is negligable. The only difference I can think of would be that we would no longer have to worry about preserving unicode by hand. It's an inconvenience, but that's about it. Nothing mission-critical. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hdbi-1.0.0 and hdbi-postgresql-1.0.0
On Wed, Jul 31, 2013 at 09:45:50AM +0600, Alexey Uimanov wrote: Hello, haskellers. This is the first release of HDBI (Haskell Database Independent interface). Hi, thanks for this Alexey. It's great that there is continued development of this really important infrustructure for Haskell. I have a question about variable interpolation, that is, using ? parameter placeholders in the query strings, as documented here: http://hackage.haskell.org/packages/archive/hdbi/1.0.0/doc/html/Database-HDBI.html I know postgresql-simple does this, and presumably database access libraries in other languages do this too. What is the rationale for this when in Haskell we have safer methods of interpolation at our disposal (for example HoleyMonoid)? Is it simply a matter of using the most familiar interface, or is there a deeper reason this is necessary? Thanks, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock GSOC project progress
Hi Roman, However, the decision to use Attoparsec (instead of Parsec, say) strikes me as a bit odd, as it wasn't intended for parsing source code. In particular, I'm concerned with error messages this parser would produce. In addition to what Mateusz already said, I want to briefly summarize my justification for using Attoparsec: * Attoparsec's backtracking behavior is much easier to work with than Parsec's * There is no such thing as a parse error in Markdown, and I think we should try to make this true for Haddock markup, too Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hdbi-1.0.0 and hdbi-postgresql-1.0.0
Alexey,
Regarding named parameters - another option is to use numbered parameters
like :1, :2 etc. It will help with repeated parameters at least. I didn't
understandthe first Bardur's point about different SQL strings though.
Kind regards,
Kirill Zaborsky
2013/7/31 Alexey Uimanov s9gf4...@gmail.com
Regard parameterized SQL: It might be worth using named parameters (e.g.
:foo and :bar or something like that) rather than ? as
placeholders in SQL/prepared SQL. This will make it slightly more
flexible if you need to provide different SQL strings for different
databases, but want to reuse the code which does the actual running of
the SQL. It's also more flexible if you need to repeat parameters -- the
latter is typical with PostgreSQL if you want to emulate
update-or-insert in a single SQL statement
Named parameters might be more flexible, but it is need to think hard
about how to implement this.
If you are using named parameters you need to pass not just list
[SqlValue] as parameters,
but Map Text SqlValue or something. So named parameters will not be
compatible with unnamed and will need
separate query parser.
Regarding migrations: If you haven't already, please have a look at
Liquibase (http://www.liquibase.org/documentation/index.html) before
attempting to implement migrations. The most important attributes of
Liquibase are:
What I am trying to implement is not a new migration system, but just the
common interface for
simple schema actions, here is my in-mind draft:
newtype TableName = TableName Text
data TableDescription = TableDescription
{tableName :: TableName
,tableFields :: [FieldDescription]
}
class (Connection con) = Introspect con where
getTableNames:: con - IO [TableName]
describeTable :: con - TableName - IO TableDescription
getIndexes :: con - [IndexDescription]
class (Connection con) = SchemaChange con where
createTable :: con - TableDescription - IO ()
dropTable :: con - TableName - IO ()
addColumn :: con - TableName - FieldDescription - IO ()
...
This typeclasses must provide database-independent schema introspection
and changing.
Migration system can be anything you want.
I also have the idea do not throw the exceptions in IO but return (Either
SqlError a) from
all the Connection and Statement methods for safe data processing. What do
you think about ?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
You received this message because you are subscribed to a topic in the
Google Groups Haskell-cafe group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/haskell-cafe/9X2J65gXGXs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
haskell-cafe+unsubscr...@googlegroups.com.
To post to this group, send email to haskell-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/haskell-cafe.
For more options, visit https://groups.google.com/groups/opt_out.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hdbi-1.0.0 and hdbi-postgresql-1.0.0
On 2013-07-31 09:22, Alexey Uimanov wrote: Regard parameterized SQL: It might be worth using named parameters (e.g. :foo and :bar or something like that) rather than ? as placeholders in SQL/prepared SQL. This will make it slightly more flexible if you need to provide different SQL strings for different databases, but want to reuse the code which does the actual running of the SQL. It's also more flexible if you need to repeat parameters -- the latter is typical with PostgreSQL if you want to emulate update-or-insert in a single SQL statement Named parameters might be more flexible, but it is need to think hard about how to implement this. If you are using named parameters you need to pass not just list [SqlValue] as parameters, but Map Text SqlValue or something. So named parameters will not be compatible with unnamed and will need separate query parser. The use case I'm thinking of it something like this: reportSQL :: DatabaseType - SQL reportSQL MySQL = SELECT ... custName = :custName ... INTERSECTION SELECT ... custName = :custName reportSQL PostgreSQL = SELECT ... AS cust WHERE cust.custName = :custName FROM SELECT ... AS foo WHERE foo.custName = cust.custName For this fictitious example we imagine that PostgreSQL can handle a nested query of some particular shape where we need an INTERSECTION query in MySQL. Obviously this is a made up example, but you get the idea. The point is that the MySQL query may need to refer to the :custName parameter multiple times whereas the PostgreSQL one doesn't. Similarly the positions in the SQL may need to be different. You perhaps still want to have a way to run both variants using the exact same code: runReport :: DatabaseType - Text - IO whatever runReport databaseType customerName = do result - runSQLWithParameters (reportSQL databaseType) [(custName, customerName)] ... do stuff with result ... return whatever Of course this being Haskell you can always use higher-order functions (e.g. a function DatabaseType - Text - IO QueryResult which encompasses the runSQLWithParameters *and* reportSQL function, but then you're mixing up the running of the query with the query itself) for similar purposes, but I tend to find named parameters of this type to be quite useful for readability. As Kirill mentioned, you can also use numbered parameters, but I tend to like named parameters for readability. Implementation should be reasonably simple: Replace all :xyz (or whatever syntax you choose) parameters in input with $n and maintain a map which tells you which parameter $1, $2, etc. correspond to. Anyway, this is an issue I've sometimes run across with JDBC (which uses ?) in particular and it can be very annoying. Perhaps the best thing in Haskell would be to just avoid raw SQL entirely in favor of combinators, but then you often end up with suboptimal SQL which can't really exploit all the features of your chosen database. Even so it would be nice to have a DB interface/library that can hit that sweet spot where you can write your own SQL but your program won't be too tied to a single DB backend (modulo the concrete SQL). Regarding migrations: If you haven't already, please have a look at Liquibase (http://www.liquibase.org/documentation/index.html) before attempting to implement migrations. The most important attributes of Liquibase are: What I am trying to implement is not a new migration system, but just the common interface for simple schema actions, here is my in-mind draft: newtype TableName = TableName Text [--snip--] This typeclasses must provide database-independent schema introspection and changing. Migration system can be anything you want. Ah, OK, I see I just misinterpreted the bit in the package description about migrations then :). You might end up having a little trouble reconciling metadata from the different database backends, but certainly there must be *some* useful common subset of table/index/etc. metadata :). I also have the idea do not throw the exceptions in IO but return (Either SqlError a) from all the Connection and Statement methods for safe data processing. What do you think about ? I don't think I'm qualified to have an opinion either way, but perhaps http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-errors and particularly http://hackage.haskell.org/package/errors can serve as insipration :). Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hdbi-1.0.0 and hdbi-postgresql-1.0.0
On Wed, Jul 31, 2013 at 01:22:42PM +0600, Alexey Uimanov wrote: I also have the idea do not throw the exceptions in IO but return (Either SqlError a) from all the Connection and Statement methods for safe data processing. What do you think about ? I feel very strongly that you should use Either. One of the things I find worst about postgres-simple is the exceptions it throws. The benefit of Haskell is that we can do things in a Haskelly way! Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Angel 0.4.4
31.07.2013, 05:03, "Michael Xavier" mich...@michaelxavier.net:angel is a daemon "angel is a background process" sounds better. Sorry for offtopic ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hdbi-1.0.0 and hdbi-postgresql-1.0.0
The rationale is that the low-level database interface accepts parameters directly instead of inserting them inside the query manually (like HoleyMonoid would do). Postgresql-simple also does parameter substitution on haskell side. This is not safe and may cause to http://en.wikipedia.org/wiki/SQL_injection because of not properly done backquoting. Low-level database interface knows better how to work with parameters, so the driver must pass them to it instead of parameters substitution. hdbi-postgresql just replace ? to $1 sequence properly parsing and ignoring question marks inside the doublequoted identifiers, quoted literals and even dollar quoted literals 4.1.2.2. Dollar-Quoted String Constantshttp://www.postgresql.org/docs/8.2/static/sql-syntax-lexical.html 2013/7/31 Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk On Wed, Jul 31, 2013 at 09:45:50AM +0600, Alexey Uimanov wrote: Hello, haskellers. This is the first release of HDBI (Haskell Database Independent interface). Hi, thanks for this Alexey. It's great that there is continued development of this really important infrustructure for Haskell. I have a question about variable interpolation, that is, using ? parameter placeholders in the query strings, as documented here: http://hackage.haskell.org/packages/archive/hdbi/1.0.0/doc/html/Database-HDBI.html I know postgresql-simple does this, and presumably database access libraries in other languages do this too. What is the rationale for this when in Haskell we have safer methods of interpolation at our disposal (for example HoleyMonoid)? Is it simply a matter of using the most familiar interface, or is there a deeper reason this is necessary? Thanks, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hdbi-1.0.0 and hdbi-postgresql-1.0.0
On Wed, Jul 31, 2013 at 05:28:02PM +0600, Alexey Uimanov wrote: The rationale is that the low-level database interface accepts parameters directly instead of inserting them inside the query manually. [...] Low-level database interface knows better how to work with parameters, so the driver must pass them to it instead of parameters substitution. Letting the low-level database interface (I'm guessing you're talking about a C library provided by the database vendor) do the escaping certainly makes a lot of sense. However, it would still be possible to make sure that the *number* of parameters supplied matches the number of placeholders in the query string. That would make sense, don't you think? Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Angel 0.4.4
On Jul 31, 2013, at 2:41 PM, Никитин Лев leon.v.niki...@pravmail.ru wrote: 31.07.2013, 05:03, Michael Xavier mich...@michaelxavier.net: angel is a daemon angel is a background process sounds better. You're killing the joke. Sorry for offtopic ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Template Haskell and Haddock
Hi, Is there a way to access docstrings through Template Haskell ? For example, access the docstring of a function declaration ? Best regards, Jose ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
On Fri, Jul 26, 2013 at 6:44 PM, Andreas Abel andreas.a...@ifi.lmu.de wrote: mapSnd f = (id *** f) As a very small aside, this is just `second` from Control.Arrow. Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell and Haddock
On Wed, 31 Jul 2013 15:18:32 +0200 Jose A. Lopes jabolo...@google.com wrote: Is there a way to access docstrings through Template Haskell ? For example, access the docstring of a function declaration ? No, but I believe you can access comments and annotations using a ghc plugin. See https://github.com/thoughtpolice/strict-ghc-plugin for example. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
Or fmap in this case =) On Wed, Jul 31, 2013 at 11:33 AM, Erik Hesselink hessel...@gmail.comwrote: On Fri, Jul 26, 2013 at 6:44 PM, Andreas Abel andreas.a...@ifi.lmu.de wrote: mapSnd f = (id *** f) As a very small aside, this is just `second` from Control.Arrow. Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rank N Kinds
OMG! I still have 7.6.3. It has old Typeable. I misunderstood PolyKinds a bit. It looks like k /= **, k ~ ***... But we cannot use CloseKinds like data Foo (a::k) = Foo a -- catch an error Expected kind `OpenKind', but `a' has kind `k' with RankNKinds we could write: data Foo (a::**) = Foo a data Bar (a::***) = Bar a So, now the task is more easy: I'm asking for useful examples with CloseKinds with ** and higher, and any useful examples for *** and higher cheers, Wvv 29 Jul 2013 at 14:44:50, José Pedro Magalhães [via Haskell] (ml-node+s1045720n5733561...@n5.nabble.com) wrote: Hi, On Fri, Jul 26, 2013 at 10:42 PM, Wvv [hidden email] wrote: First useful use is in Typeable. In GHC 7.8 class Typeable (a::k) where ... == class Typeable (a ::**) where ... But we can't write data Foo (a::k)-(a::k)-* ... deriving Typeable Why not? This works fine in 7.7, as far as I know. Cheers, Pedro -- View this message in context: http://haskell.1045720.n5.nabble.com/Rank-N-Kinds-tp5733482p5733667.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell and Haddock
On Wed, Jul 31, 2013 at 08:29:18PM +0300, kudah wrote: On Wed, 31 Jul 2013 15:18:32 +0200 Jose A. Lopes jabolo...@google.com wrote: Is there a way to access docstrings through Template Haskell ? For example, access the docstring of a function declaration ? No, but I believe you can access comments and annotations using a ghc plugin. See https://github.com/thoughtpolice/strict-ghc-plugin for example. By default, Haddock comments are not part of GHC's AST. You need to explicitly enable it (see e.g. [1]). For code that extracts all Haddock comments by using the GHC API, you can look at [2]. Cheers, Simon [1] https://github.com/sol/doctest-haskell/blob/master/src/GhcUtil.hs#L66 [2] https://github.com/sol/doctest-haskell/blob/master/src/Extract.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rank N Kinds
That's because types that belong to most non-star kinds cannot have values. data Foo (a :: k) = Foo is okay, data Foo (a :: k) = Foo a is bad because there cannot be a field of type a :: k. So no, no useful examples exist, because you wouldn't be able to use such a data constructor even if you could declare it. Roman * Wvv vite...@rambler.ru [2013-07-31 11:40:17-0700] OMG! I still have 7.6.3. It has old Typeable. I misunderstood PolyKinds a bit. It looks like k /= **, k ~ ***... But we cannot use CloseKinds like data Foo (a::k) = Foo a -- catch an error Expected kind `OpenKind', but `a' has kind `k' with RankNKinds we could write: data Foo (a::**) = Foo a data Bar (a::***) = Bar a So, now the task is more easy: I'm asking for useful examples with CloseKinds with ** and higher, and any useful examples for *** and higher cheers, Wvv 29 Jul 2013 at 14:44:50, José Pedro Magalhães [via Haskell] (ml-node+s1045720n5733561...@n5.nabble.com) wrote: Hi, On Fri, Jul 26, 2013 at 10:42 PM, Wvv [hidden email] wrote: First useful use is in Typeable. In GHC 7.8 class Typeable (a::k) where ... == class Typeable (a ::**) where ... But we can't write data Foo (a::k)-(a::k)-* ... deriving Typeable Why not? This works fine in 7.7, as far as I know. Cheers, Pedro -- View this message in context: http://haskell.1045720.n5.nabble.com/Rank-N-Kinds-tp5733482p5733667.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rank N Kinds
How about this, I found it bt myself: data TupleList (t :: **) = TupleNil | TupleUnit t (TupleList t) fstL :: TupleList (a - **) - a fstL TupleNil = error TupleList2 is TupleNil fstL (TupleUnit a _ ) = a sndL :: TupleList (* - a - **) - a sndL TupleNil = error TupleList2 is TupleNil sndL (TupleUnit a TupleNil ) = error TupleList2 is TupleUnit a TupleNil sndL (TupleUnit _ (TupleUnit a _ ) ) = a headL :: TupleList (a - **) - a headL TupleNil = error TupleList2 is TupleNil headL (TupleUnit a _ ) = a tailL :: TupleList (* - a) - a tailL TupleNil = error TupleList2 is TupleNil tailL (TupleUnit _ a ) = a instance Functor (TupleList (a :: **)) where fmap _ TupleNil = TupleNil fmap f (TupleUnit x xs) = TupleUnit (f x) (fmap xs) tupleL :: TupleList ( (Int :: *) - (String :: *) - (Bool :: *) ) tupleL = TupleUnit 5 (TupleUnit inside tuple (TupleUnit True TupleNil))) fstTuppleL :: Int fstTuppleL = fstL tupleL -- = 2 sndTuppleL :: String sndTuppleL = sndL tupleL -- = inside tuple tlTuppleL :: TupleList ( (String :: *) - (Bool :: *) ) tlTuppleL = tailL tupleL -- = TupleUnit inside tuple (TupleUnit True TupleNil)) cheers, Wvv 31 Jul 2013 at 22:48:19, Roman Cheplyaka-2 [via Haskell] (ml-node+s1045720n5733671...@n5.nabble.com) wrote: That's because types that belong to most non-star kinds cannot have values. data Foo (a :: k) = Foo is okay, data Foo (a :: k) = Foo a is bad because there cannot be a field of type a :: k. So no, no useful examples exist, because you wouldn't be able to use such a data constructor even if you could declare it. Roman * Wvv [hidden email] [2013-07-31 11:40:17-0700] OMG! I still have 7.6.3. It has old Typeable. I misunderstood PolyKinds a bit. It looks like k /= **, k ~ ***... But we cannot use CloseKinds like data Foo (a::k) = Foo a -- catch an error Expected kind `OpenKind', but `a' has kind `k' with RankNKinds we could write: data Foo (a::**) = Foo a data Bar (a::***) = Bar a So, now the task is more easy: I'm asking for useful examples with CloseKinds with ** and higher, and any useful examples for *** and higher cheers, Wvv 29 Jul 2013 at 14:44:50, José Pedro Magalhães [via Haskell] ([hidden email]) wrote: Hi, On Fri, Jul 26, 2013 at 10:42 PM, Wvv [hidden email] wrote: First useful use is in Typeable. In GHC 7.8 class Typeable (a::k) where ... == class Typeable (a ::**) where ... But we can't write data Foo (a::k)-(a::k)-* ... deriving Typeable Why not? This works fine in 7.7, as far as I know. Cheers, Pedro -- View this message in context: http://haskell.1045720.n5.nabble.com/Rank-N-Kinds-tp5733482p5733667.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://haskell.1045720.n5.nabble.com/Rank-N-Kinds-tp5733482p5733672.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock GSOC project progress
On 31/07/2013, at 8:16 PM, Simon Hengel wrote: * There is no such thing as a parse error in Markdown, and I think we should try to make this true for Haddock markup, too It is very far from clear that this is a virtue in Markdown. In trying to learn Markdown, I found it an excessively tiresome defect. Whenever I was trying to learn how to produce some combination of effects, instead of Markdown telling me at THIS point you had something I wasn't expecting, it would just produce incorrect output, defined as anything other than what I intended. It also meant that two different Markdown processors would accept the same text silently but do different things with it. This is one of the reasons I won't use Markdown. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
