, Jun 14, 2014 at 7:48 AM, Mikhail Vorozhtsov
mikhail.vorozht...@gmail.com wrote:
Hello lists,
As some of you may know, GHC's support for Unicode characters in lexemes is
rather crude and hence prone to inconsistencies in their handling versus the
ASCII counterparts. For example, APOSTROPHE is treated
On 06/17/2014 03:13 AM, Tsuyoshi Ito wrote:
Hello,
Mikhail Vorozhtsov mikhail.vorozht...@gmail.com wrote:
I also worry (although not based on anything particular you said)
whether this will not change meaning of any existing programs. Does it
only allow new programs?
As far as I can see
On 06/16/2014 04:26 AM, Mateusz Kowalczyk wrote:
On 06/14/2014 04:48 PM, Mikhail Vorozhtsov wrote:
Hello lists,
As some of you may know, GHC's support for Unicode characters in lexemes
is rather crude and hence prone to inconsistencies in their handling
versus the ASCII counterparts
Hello lists,
As some of you may know, GHC's support for Unicode characters in lexemes
is rather crude and hence prone to inconsistencies in their handling
versus the ASCII counterparts. For example, APOSTROPHE is treated
differently from PRIME:
λ data a +' b = Plus a b
interactive:3:9:
Hello lists,
I'm pleased to announce the first release of data-textual[1], a library
that provides human-friendly counterparts (called Printable/Textual) of
the compiler-friendly Show/Read type classes. The library is intended to
be used for printing and parsing of non-compound and
Hello lists,
I'm pleased to announce the first release of data-textual[1], a library
that provides human-friendly counterparts (called Printable/Textual) of
the compiler-friendly Show/Read type classes. The library is intended to
be used for printing and parsing of non-compound and
Hello,
I was writing a library for working with IP addresses when I found
myself puzzled with the number of contexts in which the textual
representation of an address could be used: plain strings, bytestring
builders (ASCII/UTF8), text builders, pretty printers, etc. I could've
just written
Hi.
I'm pleased to announce my new little library, data-dword[1]. It
provides Template Haskell utilities for defining binary word data types
from low and high halves, e.g.
data Word96 = Word96 Word32 Word64 -- strictness is configurable
data Int96 = Int96 Int32 Word64
-- All instances are
On 10/11/2012 06:09 PM, Henning Thielemann wrote:
On Thu, 11 Oct 2012, Mikhail Vorozhtsov wrote:
I'm pleased to announce my new little library, data-dword[1]. It
provides Template Haskell utilities for defining binary word data
types from low and high halves, e.g.
data Word96 = Word96 Word32
On 07/18/2012 07:25 PM, Simon Peyton-Jones wrote:
Folks
Mikhail has improved Template Haskell’s handling of INLINE pragmas,
SPECIALISE pragmas, and RULES. I plan to commit his patch:
http://hackage.haskell.org/trac/ghc/ticket/7064
Will the patch make it to 7.6? I have 6 unpublished libraries
Hi Simon.
On Wed, Jul 18, 2012 at 7:25 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Mikhail has improved Template Haskell’s handling of INLINE pragmas,
SPECIALISE pragmas, and RULES. I plan to commit his patch
BTW, is there a reason why you use commit messages to attribute other
Good news everyone. LambdaCase and MultiWayIf are now in HEAD. Thanks
for participating in the final push!
On Thu, Jul 5, 2012 at 9:42 PM, Mikhail Vorozhtsov
mikhail.vorozht...@gmail.com wrote:
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being
Good news everyone. LambdaCase and MultiWayIf are now in HEAD. Thanks
for participating in the final push!
On Thu, Jul 5, 2012 at 9:42 PM, Mikhail Vorozhtsov
mikhail.vorozht...@gmail.com wrote:
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being
On 07/05/2012 09:42 PM, Mikhail Vorozhtsov wrote:
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look
On 07/12/2012 04:27 AM, Iavor Diatchki wrote:
Hello,
I am late to the discussion and this is not entirely on topic, for which
I apologize, but I like the multi-branch case syntax someone mentioned
earlier:
Writing:
case
| p1 - e1
| p2 - e2
| ...
desugars to:
case () of
_
On 07/10/2012 01:09 AM, Bardur Arantsson wrote:
On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote:
On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout context. The
pressing
need is really
On 07/10/2012 01:53 PM, Simon Peyton-Jones wrote:
| I strongly favor a solution where lambda-case expressions start with \,
| because this can be generalized to proc expressions from arrow syntax
| simply by replacing the \ with proc.
|
| Take, for example, the following function definition:
|
|
Hi Simon.
On 07/09/2012 08:23 PM, Simon Marlow wrote:
On 07/07/2012 16:07, Strake wrote:
On 07/07/2012, Jonas Almström Duregård jonas.dureg...@chalmers.se
wrote:
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my preferences in order (all are single argument
On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout context. The
pressing
need is really for a combination of '\' and 'case', that is
single-argument so
that we don't have to write parentheses. I think
On 07/09/2012 09:49 PM, Simon Marlow wrote:
On 09/07/2012 15:04, Mikhail Vorozhtsov wrote:
Hi Simon.
On 07/09/2012 08:23 PM, Simon Marlow wrote:
On 07/07/2012 16:07, Strake wrote:
On 07/07/2012, Jonas Almström Duregård jonas.dureg...@chalmers.se
wrote:
Couldn't we use \\ for multi-case
On 07/09/2012 11:22 PM, Wolfgang Jeltsch wrote:
Am Montag, den 09.07.2012, 21:04 +0700 schrieb Mikhail Vorozhtsov:
Could you express your opinion on the case comma sugar, i.e.
case x, y of
P1, P2 - ...
P3, P4 - ...
as sugar for
case (# x, y #) of
(# P1, P2 #) - ...
(# P3, P4
On 07/06/2012 05:47 AM, Donn Cave wrote:
The `multi-clause lambda' seems more elegant, if the syntactical
problems could be worked out. I mean, unnamed functions are thus
just like named functions, something that you'd probably think to
try just as soon as you needed the feature.
I don't
On 07/05/2012 10:22 PM, wagne...@seas.upenn.edu wrote:
Quoting Mikhail Vorozhtsov mikhail.vorozht...@gmail.com:
After 21 months of occasional arguing the lambda-case proposal(s) is
in danger of being buried under its own trac ticket comments. We need
fresh blood to finally reach an agreement
On 07/06/2012 02:31 AM, Tyson Whitehead wrote:
On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax
On 07/05/2012 09:42 PM, Mikhail Vorozhtsov wrote:
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the ticket[2], vote and comment on the proposals!
On 07/06/2012 04:33 AM, Twan van Laarhoven wrote:
On 2012-07-05 23:04, Edward Kmett wrote:
A similar generalization can be applied to the expression between case
and of
to permit a , separated list of expressions so this becomes applicable
to the
usual case construct. A naked unparenthesized ,
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the ticket[2], vote and comment on the proposals!
On 02/07/2012 06:49 PM, Yves Parès wrote:
Are there documentation on constraints being types, how they can be
declared/handled and what are the interests?
The GHC User's Guide has (somewhat short) section
http://www.haskell.org/ghc/docs/latest/html/users_guide/constraint-kind.html
Blog posts:
On 02/07/2012 04:05 PM, Gábor Lehel wrote:
On Tue, Feb 7, 2012 at 7:23 AM, Mikhail Vorozhtsov
mikhail.vorozht...@gmail.com wrote:
Even better, you can write
type ExistentialWith c e = (Existential e, c ~ ConstraintOf e)
instead of
class(Existential e, c ~ ConstraintOf e
On 02/06/2012 03:32 AM, Gábor Lehel wrote:
There's a common pattern in Haskell of writing:
data E where E :: C a = a - E
also written
data E = forall a. C a = E a
I recently uploaded a package to Hackage which uses the new
ConstraintKinds extension to factor this pattern out into an Exists
On 01/29/2012 11:55 PM, Edward Z. Yang wrote:
Excerpts from Mikhail Vorozhtsov's message of Sun Jan 29 05:34:17 -0500 2012:
[snip]
I think it is one of the simplest layouts one can some up with. I'll try
to explain the motivation behind each inclusion.
ABORTS(μ) ⊆ RECOVERABLE_ZEROS(μ)
I'm
On 01/24/2012 10:56 PM, Edward Z. Yang wrote:
Excerpts from Mikhail Vorozhtsov's message of Tue Jan 24 07:26:35 -0500 2012:
Sure, but note that evaluate for IO is implemented with seq# under the hood,
so as long as you actually get ordering in your monad it's fairly
straightforward
to
On 01/22/2012 02:47 AM, Edward Z. Yang wrote:
Excerpts from Mikhail Vorozhtsov's message of Sat Jan 21 09:25:07 -0500 2012:
But I also believe that you can't use this as justification to stick your
head in the sand, and pretend bottoms don't exist (regardless of whether or
not we'rd talking
On 01/18/2012 10:43 PM, Edward Z. Yang wrote:
Excerpts from Mikhail Vorozhtsov's message of Wed Jan 18 08:47:37 -0500 2012:
Well, that's the kind of language we live in. The denotation of our language
always permits for bottom values, and it's not a terribly far jump from there
to undefined
On 01/18/2012 01:52 AM, Brandon Allbery wrote:
On Tue, Jan 17, 2012 at 06:29, Mikhail Vorozhtsov
mikhail.vorozht...@gmail.com mailto:mikhail.vorozht...@gmail.com wrote:
I wouldn't be too optimistic about convincing GHC HQ. Even making
Applicative a superclass of Monad can make Haskell98
On 01/18/2012 02:45 AM, Edward Z. Yang wrote:
Excerpts from Mikhail Vorozhtsov's message of Tue Jan 17 06:29:12 -0500 2012:
The vehicle of implementation here is kind of important. If they are
implemented
as asynchronous exceptions, I can in fact still throw in this universe: I just
attempt
On 01/17/2012 03:00 AM, Edward Z. Yang wrote:
[snip]
I don't think it makes too much sense have thing pick off a menu of
Abort/Recover/Finally from a semantics perspective:
It's easy to imagine monads that have an instance of one of the classes but
not of the others
I'd like to see some
On 01/16/2012 02:15 PM, Edward Z. Yang wrote:
Hello Mikhail,
Hi.
Sorry, long email. tl;dr I think it makes more sense for throw/catch/mask to
be bundled together, and it is the case that splitting these up doesn't address
the original issue monad-control was designed to solve.
On 01/10/2012 11:12 PM, Edward Z. Yang wrote:
Excerpts from Mikhail Vorozhtsov's message of Tue Jan 10 09:54:38 -0500 2012:
On 01/10/2012 12:17 AM, Edward Z. Yang wrote:
Hello Mikhail,
Hi.
(Apologies for reviving a two month old thread). Have you put some thought into
whether or not these
On 01/10/2012 12:17 AM, Edward Z. Yang wrote:
Hello Mikhail,
Hi.
(Apologies for reviving a two month old thread). Have you put some thought into
whether or not these extra classes generalize in a way that is not /quite/ as
general as MonadBaseControl (so as to give you the power you need) but
Hi.
I grew up tired of counting milliseconds, so I wrote a small library[1]
that allows me to specify time units for timeouts and convert between
them. The library also provides wrapped versions of 'timeout' and
'threadDelay' functions:
threadDelay $ 1 # Minute + 30 # Second
Nanosecond
On 11/14/2011 06:55 AM, Bas van Dijk wrote:
Hi Mikhail,
your type class:
class MonadAbort e μ ⇒ MonadRecover e μ | μ → e where
recover ∷ μ α → (e → μ α) → μ α
looks a lot like the MonadCatchIO type class from MonadCatchIO-transformers:
class MonadIO m = MonadCatchIO m where
catch ::
On 11/12/2011 07:34 AM, Bas van Dijk wrote:
Are you going to release a new version of monad-control right away
Not just yet. I've split `monad-control` into two packages:
* `monad-control`: just exports `Control.Monad.Trans.Control`. This part is
finished.
* `lifted-base`: wraps all modules
Hi Cafe.
I've been using these three small transformer libraries for awhile, so
it's probably time to announce them.
transformers-base[1] introduces a generalized version of MonadIO,
MonadBase (BaseM in monadLib terms). It's very useful when you are
trying to make a stateful API work in
Hi Cafe,
Here is another example of why 'let' should be sometimes generalised.
I've been recently playing with indexed monads (for JSON processing) and
found out that the following code fails to typecheck:
{-# LANGUAGE MonoLocalBinds #-}
data M t t' a = M
ipure :: a - M t t a
ipure a = M
46 matches
Mail list logo
