this is true; however, it is likely that it would be much faster for me
to read in word8s and parse them to Ints myself than to read in Chars
(using the old libraries) and parse those to ints (I've done some
experiments and the overhead for reading haskell Chars is very
non-negligible). i'd like t
On Mon, 4 Aug 2003, Ashley Yakeley wrote:
> At 2003-08-04 22:33, Ben Rudiak-Gould wrote:
>
> >This illustrates what you pointed out earlier, that the
> >program's semantics can be changed by adding explicit type signatures
> >which include implicitly-parameterized parameters.
>
> But wasn't avoi
I have a small question relating to literate haskell programs that
use the \begin{code} \end{code} style. Am I correct to assume that
\end{code} inside a string should be recognized as being inside a
string. The report seems to say this, but the unlit that is
distributed with ghc doesn't grok this
Immanuel Litzroth <[EMAIL PROTECTED]> writes:
> I have a small question relating to literate haskell programs that
> use the \begin{code} \end{code} style. Am I correct to assume that
> \end{code} inside a string should be recognized as being inside a
> string. The report seems to say this, but t
| I just figured out why the monomorphism restriction interacts so
weirdly
| with implicit parameters, and how to fix it.
I'm afraid that I have not read all of the recent exciting flood of
messages carefully, but I do remember that the interaction of the
monomorphism restriction with implicit par
This message illustrates how safe casting with multiple universes can
be extended to new user-defined, polymorphic datatypes. We show a
_portable_ mapping of polymorphic types to integers. Different
instances of a polymorphic type map to different integers. Phantom
types can be either disregarded
At 2003-08-04 18:19, Ben Rudiak-Gould wrote:
>> ((\a -> ((a,[EMAIL PROTECTED] -> @x) [EMAIL PROTECTED] = 2})) ([EMAIL PROTECTED] ->
>> @x),[EMAIL PROTECTED] -> @x) [EMAIL PROTECTED] = 1}
> ^^^
>> (([EMAIL PROTECTED] -> @x,[EMAIL PROTECTED] -> @x) [EMAIL PROTECT
I just figured out why the monomorphism restriction interacts so weirdly
with implicit parameters, and how to fix it.
We all know that when the monomorphism restriction is turned on, the
following doesn't work:
let f = (<) in (f 1 2, f 'a' 'b')
On the other hand, the following does work:
