The Travis folks have decided they want to support Haskell better (multiple
compiler versions):
https://github.com/travis-ci/travis-ci/issues/882#issuecomment-20165378
(Yay!) They're asking for someone to help them up with setup scripts.
They mention their cookbook collection here:
https:
Simon,
I see your point. Essentially, the original proposal keeps the
namespace for field names syntactically distinguishable from that of
functions, so that the type given to "r.foo" doesn't depend on what is
in scope. (.foo) is always defined and it is always a function of
type "(r { foo::t })
> Malcolm Wallace me.com> writes:
>
> >>
> >> With the orthogonal proposal, f is equivalent to
> >>f r b = foo r && b
>
> I believe Simon's point is that, if dot is special, we can infer
the "Has" type above, even if the compiler is
> not currently aware of any actual record types that con
On 28 Jun 2013, at 12:16, AntC wrote:
> Thanks Simon, I'm a little puzzled what your worry is.
>
>> f r b = r.foo && b
>> With dot-notation baked in (non-orthogonally), f would get the type
>>
>> f :: (r { foo::Bool }) => r -> Bool -> Bool
>>
>> With the orthogonal proposal, f is eq
> Simon Peyton-Jones microsoft.com> writes:
>
> I have, however, realised why I liked the dot idea. Consider
>
> f r b = r.foo && b
>
Thanks Simon, I'm a little puzzled what your worry is.
> With dot-notation baked in (non-orthogonally), f would get the type
>
> f :: (r { foo::Bo
Unfortunately the two machines are fairly wildly different in their
hardware characteristics. The OS X machine has 4GB of RAM; 8 Core i7.
The Linux machine has 16GB, but only a 4-core i5. And they have
different clock speeds.
I'll get GCC 4.8 on my OS X machine so I can force a build with it and
c
On 26/06/13 04:13, Austin Seipp wrote:
Thanks Manuel!
I have an update on this work (I am also CC'ing glasgow-haskell-users,
as I forgot last time.) The TL;DR is this:
* HEAD will correctly work with Clang 3.4svn on both Linux, and OS X.
* I have a small, 6-line patch to Clang to fix the bu
Hi Evan,
> 1 - Add an option to add a 'deriving (Lens)' to record declarations.
> That makes the record declare lenses instead of functions.
Well, no, that's exactly the kind of magic programming language hackery,
that Haskell shouldn't be part of.
Deriving should only add something, but not ch
| Folks, I'm keenly aware that GSoC has a limited timespan; and that there
| has already been much heat generated on the records debate.
I am also keenly aware of this. I think the plan Ant outlines below makes
sense; I'll work on it with Adam.
I have, however, realised why I liked the dot idea
