I wrote:
In addition, OverloadedStrings is unsound.
J. Garrett Morris wrote:
fromString can throw errors, just like fromInteger
This is true; the use of polymorphism
for numeric literals is also unsound.
However, in practice, it is rare for there to be
dangerous instances of the numeric type
On Mon, Apr 23, 2012 at 11:10 PM, Yitzchak Gale g...@sefer.org wrote:
This is true; the use of polymorphism for numeric literals is also
unsound.
By this logic, head is unsound, since head [] throws an error.
Haskell types are pointed; Haskell computations can diverge. What
happens after the
Greg Weber wrote:
I very much agree with you. However, when we complain about something
essentially we are asking others to prioritize it ahead of other
things. I don't think any more visibility of this issue is going to
improve its prioritization. I suspect your only way forward right now
is
On Tue, Apr 24, 2012 at 02:14, J. Garrett Morris jgmor...@cs.pdx.eduwrote:
On Mon, Apr 23, 2012 at 11:10 PM, Yitzchak Gale g...@sefer.org wrote:
This is true; the use of polymorphism for numeric literals is also
unsound.
By this logic, head is unsound, since head [] throws an error.
On Tue, Apr 24, 2012 at 9:26 AM, Yitzchak Gale g...@sefer.org wrote:
Greg Weber wrote:
I very much agree with you. However, when we complain about something
essentially we are asking others to prioritize it ahead of other
things. I don't think any more visibility of this issue is going to
J. Garrett Morris wrote:
By this logic, head is unsound, since head [] throws an error.
Haskell types are pointed; Haskell computations can diverge.
Well, there are those who would actually agree with
that and banish 'head' and friends from the language.
But I'll agree with you here.
[As an
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 common
On Tue, Apr 24, 2012 at 9:26 AM, Yitzchak Gale g...@sefer.org 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
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
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
I see what you mean -- many libraries provide conveniences like that
(like TagSoups `takeWhile (~== /a) 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
On Tue, Apr 24, 2012 at 08:32, Michael Snoyman mich...@snoyman.com 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
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 11:36 AM, Erik Hesselink hessel...@gmail.com wrote:
On Tue, Apr 24, 2012 at 08:32, Michael Snoyman mich...@snoyman.com wrote:
Here's a theoretically simple solution to the problem. How about
adding a new method to the IsString typeclass:
isValidString :: String -
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 g...@sefer.org wrote:
Simon Peyton-Jones wrote:
If you want validation of literal strings, then TH quasiquotes are the way
to go:
I agree.
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
On Tue, Apr 24, 2012 at 12:35 PM, Yitzchak Gale g...@sefer.org 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
On Tue, Apr 24, 2012 at 10:55, Michael Snoyman mich...@snoyman.com wrote:
On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink hessel...@gmail.com wrote:
On Tue, Apr 24, 2012 at 08:32, Michael Snoyman mich...@snoyman.com wrote:
Here's a theoretically simple solution to the problem. How about
- 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:
Thanks
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
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.
you
On Tue, Apr 24, 2012 at 1:08 PM, Erik Hesselink hessel...@gmail.com wrote:
On Tue, Apr 24, 2012 at 10:55, Michael Snoyman mich...@snoyman.com wrote:
On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink hessel...@gmail.com wrote:
On Tue, Apr 24, 2012 at 08:32, Michael Snoyman mich...@snoyman.com
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 g...@sefer.org wrote:
Markus Läll wrote:
You do know, that you already *can* have safe Text and ByteString from
On 24/04/2012 11:08, Erik Hesselink wrote:
On Tue, Apr 24, 2012 at 10:55, Michael Snoymanmich...@snoyman.com wrote:
On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselinkhessel...@gmail.com wrote:
On Tue, Apr 24, 2012 at 08:32, Michael Snoymanmich...@snoyman.com wrote:
Here's a theoretically
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 much,
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
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.
I'm
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 anything to do
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
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
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
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 `something=illegal :: XML' and have the compiler tell him at
compile-time that this is not
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
Hello Simon,
Sorry for the delay.
On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlow marlo...@gmail.com 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
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
could be
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
36 matches
Mail list logo
