On 12-04-24 10:11 PM, wren ng thornton wrote:
To the extent that ByteString's instance runs into issues with high
point codes, that strikes me as a bug in virtue of poor foresight.
Consider, for instance, the distinction between integral and
non-integral numeric literals. We recognize that (0.1 :
> Thank you for the answer.
> I'll be working on another project during the summer, but I'm still
> interested in making interface files load faster.
>
> The idea that I currently like the most is to make it possible to save
> and load objects in the "GHC heap format". That way, deserialisation
> c
Hello Simon,
Sorry for the delay.
On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlow wrote:
>
>> Questions:
>>
>> Would implementing this optimisation be a worthwhile/realistic GSoC
>> project?
>> What are other potential ways to bring 'ghc -c' performance up to par
>> with 'ghc --make'?
>
>
> My gue
On 4/24/12 3:35 PM, Markus Läll wrote:
For what I understand, and putting words in his mouth, he wants to
write `"" :: XML' and have the compiler tell him at
compile-time that this is not valid XML (if it actually is, imagine
that there's something invalid between the double quotes). I.e he
wants
> So if every value, when forced, can crash your program, possibly depending
> on what type it's instantiated to, why are we so concerned about String
> literals behaving like everything else?
Well, that was exactly my point. Some people think it's *more likely*
that people will write crashing fr
I'm the one arguing in defense of the current state of
OverloadedStrings, and no secret that Yitz has been the main opponent
of it.
For what I understand, and putting words in his mouth, he wants to
write `"" :: XML' and have the compiler tell him at
compile-time that this is not valid XML (if it
I think my point was more along the lines that every *value*, regardless of
whether it's a function or not, can be partial (ignoring primitive types
and such). I can hand you a list where the third Int in it will cause you
to crash if you force it.
In that sense, whether every numeric literal expa
>From what I can see the core of the disagreement is that some people
believe fromString will tempt misuse (i.e. using *easily* partial
functions, like XML validation), while others don't think it's that
likely. Indeed misusing IsString is worse than your average partial
function because of the gl
Hi,
Yitzhack Gale wrote:
> Wouldn't it be ironic if the one thing that every language
> other than Haskell is able to check at compile time,
> namely the static syntax of string literals, could only be
> checked at run time in Haskell?
I don't really see the irony, I'm afraid, as nothing really
On 24/04/2012 15:19, Yitzchak Gale wrote:
Simon Marlow wrote:
In this thread people are using the term "safe" to
mean "total". We already overload "safe" too much, might it be a better
idea to use "total" instead?
I'm not sure what you're talking about. I don't see how
this thread has anythin
Simon Marlow wrote:
> In this thread people are using the term "safe" to
> mean "total". We already overload "safe" too much, might it be a better
> idea to use "total" instead?
I'm not sure what you're talking about. I don't see how
this thread has anything to do with total vs. partial
functions
Daniel Peebles wrote:
> Why are potentially partial literals scarier than the fact that every value
> in the language could lead to an exception when forced?
That's a legitimate question, but it's strange to hear it from
you.
People ask that same question about Haskell's static
type system. Why b
On 24/04/2012 14:14, Daniel Peebles wrote:
Why are potentially partial literals scarier than the fact that every
value in the language could lead to an exception when forced?
My thoughts exactly. In this thread people are using the term "safe" to
mean "total". We already overload "safe" too
On 24/04/2012 11:08, Erik Hesselink wrote:
On Tue, Apr 24, 2012 at 10:55, Michael Snoyman wrote:
On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink wrote:
On Tue, Apr 24, 2012 at 08:32, Michael Snoyman wrote:
Here's a theoretically simple solution to the problem. How about
adding a new method
Why are potentially partial literals scarier than the fact that every value
in the language could lead to an exception when forced?
On Tue, Apr 24, 2012 at 5:35 AM, Yitzchak Gale wrote:
> Markus Läll wrote:
> > You do know, that you already *can* have safe Text and ByteString from
> > an overlo
On Tue, Apr 24, 2012 at 1:08 PM, Erik Hesselink wrote:
> On Tue, Apr 24, 2012 at 10:55, Michael Snoyman wrote:
>> On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink wrote:
>>> On Tue, Apr 24, 2012 at 08:32, Michael Snoyman wrote:
Here's a theoretically simple solution to the problem. How abo
Hi,
Am Dienstag, den 24.04.2012, 19:50 +0900 schrieb Jens Petersen:
> >- debian/patches/armhf_llvm_abi: Pass -float-abi=hard to llc on armhf if
> > __ARM_PCS_VFP is defined (needs to be preprocessed for this)
> >- debian/rules: Define __ARM_PCS_VFP on armhf for the above patch.
> >
>
But if you want a string to be, say, an XML document then you want to
turn the string literal into an XML syntax tree (which is correct by
the definition of the data types representing it). As this conversion
can fail (all unicode strings are not valid representations of an XML
syntax tree), you ne
> - debian/patches/armhf_llvm_abi: Pass -float-abi=hard to llc on armhf if
> __ARM_PCS_VFP is defined (needs to be preprocessed for this)
> - debian/rules: Define __ARM_PCS_VFP on armhf for the above patch.
>
> you might need to set __ARM_PCS_VFP. This is the code in debian/rules:
Thank
On Tue, Apr 24, 2012 at 10:55, Michael Snoyman wrote:
> On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink wrote:
>> On Tue, Apr 24, 2012 at 08:32, Michael Snoyman wrote:
>>> Here's a theoretically simple solution to the problem. How about
>>> adding a new method to the IsString typeclass:
>>>
>>>
On Tue, Apr 24, 2012 at 12:35 PM, Yitzchak Gale wrote:
> Markus Läll wrote:
>> You do know, that you already *can* have safe Text and ByteString from
>> an overloaded string literal.
>
> Yes, the IsString instances for Text and ByteString are safe
> (I hope).
>
> But in order to use them, I have t
Markus Läll wrote:
> You do know, that you already *can* have safe Text and ByteString from
> an overloaded string literal.
Yes, the IsString instances for Text and ByteString are safe
(I hope).
But in order to use them, I have to turn on OverloadedStrings.
That could cause other string literals
You do know, that you already *can* have safe Text and ByteString from
an overloaded string literal.
On Tue, Apr 24, 2012 at 11:46 AM, Yitzchak Gale wrote:
> Simon Peyton-Jones wrote:
>> If you want validation of literal strings, then TH quasiquotes are the way
>> to go:
>
> I agree. OverloadedS
On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink wrote:
> On Tue, Apr 24, 2012 at 08:32, Michael Snoyman wrote:
>> Here's a theoretically simple solution to the problem. How about
>> adding a new method to the IsString typeclass:
>>
>> isValidString :: String -> Bool
>
> If you're going with t
Simon Peyton-Jones wrote:
> If you want validation of literal strings, then TH quasiquotes are the way to
> go:
I agree. OverloadedStrings is, in effect, an unsafe replacement
for quasiquotes. People find OverloadedStrings easier to use
than quasiquotes, so its use in that way is becoming popular
On Tue, Apr 24, 2012 at 08:32, Michael Snoyman wrote:
> Here's a theoretically simple solution to the problem. How about
> adding a new method to the IsString typeclass:
>
> isValidString :: String -> Bool
If you're going with this approach, why not evaluate the conversion
from String immediat
I see what you mean -- many libraries provide conveniences like that
(like TagSoups `takeWhile (~== "") tags' and so on). But that's
the inherent mismatch between a String-- a unicode literal --and
whatever else you want it to be, be it ASCII or bash or XML or
something else.. I think the answer to
I'm not following the details of this thread, but if you guys can come to a
conclusion and write up a design, I'd be happy to discuss it.
If you want validation of literal strings, then TH quasiquotes are the way to
go:
[url| http://this/that |]
will let you specify the parser/validato
Markus Läll wrote:
> What can go wrong when you use an overloaded string to be fromString'd
> into Text?
Here's an example:
The author of the xml-types package provides an IsString
instance for XML names, so you can conveniently
represent XML names as string literals in your source
code.
But not
On Tue, Apr 24, 2012 at 9:26 AM, Yitzchak Gale wrote:
> However, what I can do is raise the red flag. Some people
> are pushing things in directions which would cause
> OverloadStrings to become more and more ubiquitous,
> perhaps even the default. I want to make sure that the
> people who are doi
Michael Snoyman wrote:
> Here's a theoretically simple solution to the problem. How about
> adding a new method to the IsString typeclass:
> isValidString :: String -> Bool
> ...whenever GHC applies OverloadedStrings in a case
> where the type is fully known at compile time (likely the most comm
31 matches
Mail list logo
