On 1/12/11 5:05 AM, Ketil Malde wrote:
Of course, ideally you should design your types so that all possible
values are meaningful:-)
Sadly we cannot all program in Agda. :-)
Cheers,
Greg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http:/
Serge Le Huitouze writes:
> So, do you have any "methodology" for such use cases?
QuickCheck has the ==> operator, which lets you add a precondition. So
you could limit the testing of your property to values that satisfy the
precondition.
An alternative is to use newtype with a custom generato
Henning Thielemann wrote:
>
>> A code doing addition and substraction of some sort.
>> A property such as "X = (X add Y) sub Y" is easily falsifiable when
>> the number of bits of your integer is too small for your numbers.
>
> Since fix-width words represent modulo-arithmetic, your law would even
2011/1/12 Serge Le Huitouze
> Evan Laforge wrote:
> .
> So, in addition to defining the approximation (not always easy as I tried
> to "demonstrate" above) to be used in comparisons, one probably needs
> ad'hoc generators whose complexity might very well exceed that of
> the code one wants t
On 12 January 2011 21:16, Serge Le Huitouze wrote:
> Evan Laforge wrote:
>
>> QuickCheck seems to fit well when you have small input and output
>> spaces, but complicated stuff in the middle, but still simple
>> relations between the input and output. I think that's why data
>> structures are so
On Wed, 12 Jan 2011, Serge Le Huitouze wrote:
Also, I wonder how you guys do when you're trying to tests code
using a lot of numbers (be them floating point or even integer).
Machine size integers and floating point numbers are indeed nasty. I test
a lot in NumericPrelude with QuickCheck, b
Evan Laforge wrote:
> QuickCheck seems to fit well when you have small input and output
> spaces, but complicated stuff in the middle, but still simple
> relations between the input and output. I think that's why data
> structures are so easy to QuickCheck. I suppose I should look around
> for
Florian Weimer wrote:
* Jonathan Geddes:
When I write Haskell code, I write functions (and monadic actions)
that are either a) so trivial that writing any kind of unit/property
test seems silly, or are b) composed of other trivial functions using
equally-trivial combinators.
You can write in
> I should say that this reimplementation would be good. If you can
> compare two implementations (one in plain Haskell and second in
> declarative QuickCheck rules) you will be better that with only one.
This presumes I know how to write a simple but slow version. Clearly,
that's an excellent si
On Wed, Jan 5, 2011 at 7:31 PM, Chung-chieh Shan
wrote:
> Besides those example inputs and expected outputs, what about:
> If two signals are (in)compatible then after applying some simple
> transformations to both they remain (in)compatible? A certain family of
> signals is always compatible wit
* Jonathan Geddes:
> When I write Haskell code, I write functions (and monadic actions)
> that are either a) so trivial that writing any kind of unit/property
> test seems silly, or are b) composed of other trivial functions using
> equally-trivial combinators.
You can write in this style in any
Seeing all the good discussion on this thread, I think we are missing
a TDD page on our Haskell.org wiki. =)
Cheers,
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
2011/1/6 Evan Laforge :
>> QuickCheck especially is great because it automates this tedious work:
>> it fuzzes out the input for you and you get to think in terms of
>> higher-level invariants when testing your code. Since about six months
>> ago with the introduction of JUnit XML support in test-f
2011/1/6 Arnaud Bailly :
> I would supplement this excellent list of advices with an emphasis on
> the first one: Test-Driven Development is *not* testing, TDD is a
> *design* process. Like you said, it is a discipline of thought that
> forces you first to express your intent with a test, second to
I would supplement this excellent list of advices with an emphasis on
the first one: Test-Driven Development is *not* testing, TDD is a
*design* process. Like you said, it is a discipline of thought that
forces you first to express your intent with a test, second to write
the simplest thing that ca
You need both. A good static type system will tell you whether or not the
code is type-correct. It will not tell you whether or not it does what it's
supposed to do.
Consider:
sort :: [a] -> [a]
If you change sort to be:
sort = id
It will still type check, but it obviously doesn't do what it
Evan Laforge wrote in article
in
gmane.comp.lang.haskell.cafe:
> Incidentally, I've never been able to figure out how to use
> QuickCheck. Maybe it has more to do with my particular app, but
> QuickCheck seems to expect simple input data and simple properties
> that should hold relating the in
On Wed, Jan 5, 2011 at 1:27 PM, Gregory Collins wrote:
> On Wed, Jan 5, 2011 at 9:02 PM, Jonathan Geddes
> wrote:
>
>> Despite all this, I suspect that since Haskell is at a higher level of
>> abstraction than other languages, the tests in Haskell must be at a
>> correspondingly higher level than
John Zabroski wrote:
> 5. I have a hard time understanding statements like "The difficulties in
> unit testing OO code is coaxing objects into the correct state to test a
> particular property."
This is my direct experience of inheriting code written by others
without any tests and trying to add
On Wed, Jan 5, 2011 at 6:41 PM, John Zabroski wrote:
>
> 5. I have a hard time understanding statements like "The difficulties in
> unit testing OO code is coaxing objects into the correct state to test a
> particular property." Difficulty in unit testing OO code is best documented
> in Robert Bi
These are some heuristics & memories I have for myself, and you can feel
free to take whatever usefulness you can get out of it.
1. Don't confuse TDD with writing tests, in general.
2. Studies show that if you do TDD, you can write more tests than if you
write tests after you write the code. The
Jonathan Geddes wrote:
> I know that much of my code could benefit from a property test or two
> on the more complex parts, but other than that I can't think that unit
> testing will improve my Haskell code/programming practice.
One other thing I should mention that is that since a lot of
Haskell
On Wed, Jan 05, 2011 at 10:27:29PM +0100, Gregory Collins wrote:
> Once I had written the test harness, I spent literally less than a
> half-hour setting this up. Highly recommended, even if it is a (blech)
> Java program. Testing is one of the few areas where I think our
> "software engineering" t
On Wed, Jan 5, 2011 at 9:02 PM, Jonathan Geddes
wrote:
> Despite all this, I suspect that since Haskell is at a higher level of
> abstraction than other languages, the tests in Haskell must be at a
> correspondingly higher level than the tests in other languages. I can
> see that such tests would
Haskell's type system makes large classes of traditional "unit tests"
irrelevant. Here are some examples:
- Tests that simply "run" code to make sure there are no syntax
errors or typos,
- Tests that exercise simple input validation that is handled by the
type system, i.e. pa
On Wed, Jan 5, 2011 at 3:02 PM, Jonathan Geddes
wrote:
>> The Haskell type system is simply not rich enough to guarantee everything
>> you might need.
> Despite all this, I suspect that since Haskell is at a higher level of
> abstraction than other languages, the tests in Haskell must be at a
> c
> The Haskell type system is simply not rich enough to guarantee everything you
> might need.
That's true, and after giving this a bit more thought, I realized it's
not JUST the type system that I'm talking about here. There are a few
other features that make it hard for me to want to use unit/pr
On 01/05/2011 03:44 AM, Jonathan Geddes wrote:
When I write Haskell code, I write functions (and monadic actions)
that are either a) so trivial that writing any kind of unit/property
test seems silly, or are b) composed of other trivial functions using
equally-trivial combinators.
"There are tw
Erik de Castro Lopo wrote:
> Jonathan Geddes wrote:
>
>
>
>> So, am I missing the benefits of TDD in my Haskell code?
>
> Probably. I work on a project which has 4+ lines of
> haskell code (a compiler written in haskell) and has a huge
> test suite that is a vital to continued development.
Jonathan Geddes wrote:
> So, am I missing the benefits of TDD in my Haskell code?
Probably. I work on a project which has 4+ lines of
haskell code (a compiler written in haskell) and has a huge
test suite that is a vital to continued development.
I've also written relatively small function
Cafe,
In every language I program in, I try to be as disciplined as possible
and use Test-Driven Development. That is, every language except
Haskell.
There are a few great benefits that come from having a comprehensive
test suite with your application:
1. Refactoring is safer/easier
2. You have
Hello,
I think your type should be:
type Board a b c d e f g h i =
Either (Three a b c)
(Either (Three d e f)
(Either (Three g h i)
(Either (Three a d g)
(Either (Three b e h)
(Either (Three c f i)
(Either (Three a e i)
(Three c e g)))
as far as i can understand, it
On Wed, Dec 9, 2009 at 7:47 PM, wren ng thornton wrote:
> Andrew Coppin wrote:
>
>> What we're really trying to do here is attach additional information to a
>> value - information which exists only in the type checker's head, but has no
>> effect on runtime behaviour (other than determining whet
Andrew Coppin wrote:
What we're really trying to do here is attach additional information to
a value - information which exists only in the type checker's head, but
has no effect on runtime behaviour (other than determining whether we
*get* to runtime). As far as I can tell, Haskell does not pr
People in the Haskell community get awfully excited about Haskell's type
system.
When I was first learning Haskell, I found this rather odd. After all, a
"type" is just a flat name that tells the compiler how many bits to
allocate and which operations to allow, right?
As I read further, I qu
On Tue, Jun 23, 2009 at 9:25 PM, Ross Mellgren wrote:
> I'm no expert, but it seems like those constructors should return Foobar
> NoZoo, unless you're nesting so there could be a Zoo, in which case the type
> variable a should transit, for example:
>
> data Foobar a where
> Foo :: X -> Y -> Foo
I'm no expert, but it seems like those constructors should return
Foobar NoZoo, unless you're nesting so there could be a Zoo, in which
case the type variable a should transit, for example:
data Foobar a where
Foo :: X -> Y -> Foobar NoZoo
Bar :: X -> Y -> Foobar NoZoo
Baz :: Foob
On Jun 22, 2009, at 14:43 , Andrew Coppin wrote:
data Foobar a where
Foo :: X -> Y -> Foobar NoZoo
Bar :: X -> Y -> Foobar NoZoo
Zoo :: Foobar NoZoo -> Foobar Zoo
For some reason, if I do this I get endless type check errors. I
have to change the top two back to Foobar a before it will w
Ross Mellgren wrote:
This works for me:
{-# LANGUAGE EmptyDataDecls, GADTs #-}
module Main where
data NoZoo
data Zoo
newtype X = X Int deriving (Show)
newtype Y = Y Char deriving (Show)
data Foobar a where
Foo :: X -> Y -> Foobar NoZoo
Bar :: X -> Y -> Foobar NoZoo
Zoo :: Foobar N
This works for me:
{-# LANGUAGE EmptyDataDecls, GADTs #-}
module Main where
data NoZoo
data Zoo
newtype X = X Int deriving (Show)
newtype Y = Y Char deriving (Show)
data Foobar a where
Foo :: X -> Y -> Foobar NoZoo
Bar :: X -> Y -> Foobar NoZoo
Zoo :: Foobar NoZoo -> Foobar Zoo
fo
Niklas Broberg wrote:
Not nearly as annoying as this:
data Foobar a where
Foo :: X -> Y -> Foobar NoZoo
Bar :: X -> Y -> Foobar NoZoo
Zoo :: Foobar NoZoo -> Foobar Zoo
For some reason, if I do this I get endless type check errors. I have to
change the top two back to Foobar a before it w
Andrew Coppin said:
> data Foobar a where
> Foo :: X -> Y -> Foobar NoZoo
> Bar :: X -> Y -> Foobar NoZoo
> Zoo :: Foobar NoZoo -> Foobar Zoo
>
> For some reason, if I do this I get endless type check errors. I have to
> change the top two back to Foobar a before it will work. *sigh*
That c
> Not nearly as annoying as this:
>
> data Foobar a where
> Foo :: X -> Y -> Foobar NoZoo
> Bar :: X -> Y -> Foobar NoZoo
> Zoo :: Foobar NoZoo -> Foobar Zoo
>
> For some reason, if I do this I get endless type check errors. I have to
> change the top two back to Foobar a before it will work
Brent Yorgey wrote:
On Sun, Jun 21, 2009 at 09:16:12PM +0100, Andrew Coppin wrote:
Niklas Broberg wrote:
That's what GADTs are for:
data Flag = HasZoo | NoZoo
data Foobar a where
Foo :: Foobar a -> Foobar a
Bar :: Foobar a -> Foobar a
Zoo :: Foobar a -> Foobar HasZoo
O
On Sun, Jun 21, 2009 at 09:16:12PM +0100, Andrew Coppin wrote:
> Niklas Broberg wrote:
>> That's what GADTs are for:
>>
>> data Flag = HasZoo | NoZoo
>>
>> data Foobar a where
>> Foo :: Foobar a -> Foobar a
>> Bar :: Foobar a -> Foobar a
>> Zoo :: Foobar a -> Foobar HasZoo
>>
>
> Ouch #1:
David Menendez wrote:
If you don't need code that's polymorphic between Foobar HasZoo and
Foobar NoZoo, you could just newtype Foobar and only export smart
constructors.
Unfortunately I want to be able to print both of them out. (After all,
the printing algorithm is identical whether Zoo is
On Sun, Jun 21, 2009 at 4:00 PM, Andrew
Coppin wrote:
> Niklas Broberg wrote:
>>
>> On Sun, Jun 21, 2009 at 9:24 PM, Andrew
>> Coppin wrote:
>>
>>> I want the type system to track whether or not Zoo has been used in a
>>> specific value. Sure, you can check for it at runtime, but I'd be happier
>>>
>> That's what GADTs are for:
>>
>> data Flag = HasZoo | NoZoo
Eh, I wrote this a bit fast obviously (no dependent types here).
Like Daniel Fischer wrote, these should rather be separate data types, i.e.
data HasZoo
data NoZoo
The rest is still correct though.
>> data Foobar a where
>> Foo ::
Niklas Broberg wrote:
That's what GADTs are for:
data Flag = HasZoo | NoZoo
data Foobar a where
Foo :: Foobar a -> Foobar a
Bar :: Foobar a -> Foobar a
Zoo :: Foobar a -> Foobar HasZoo
Ouch #1: This appears to instantly disable deriving the Eq, Ord and Show
instances I want. :-/
_
Niklas Broberg wrote:
On Sun, Jun 21, 2009 at 9:24 PM, Andrew
Coppin wrote:
data Foobar =
Foo Foobar |
Bar Foobar |
Zoo Foobar
I want the type system to track whether or not Zoo has been used in a
specific value. Sure, you can check for it at runtime, but I'd be happier if
the type sy
Am Sonntag 21 Juni 2009 21:24:24 schrieb Andrew Coppin:
> I have a datatype with about a dozen constructors. I'd like to find a
> way to use the type system to prevent one of the constructors from being
> used in certain places. But I can't think of a way to do that.
>
> data Foobar =
> Foo F
On Sun, Jun 21, 2009 at 9:24 PM, Andrew
Coppin wrote:
> I have a datatype with about a dozen constructors. I'd like to find a way to
> use the type system to prevent one of the constructors from being used in
> certain places. But I can't think of a way to do that.
>
> data Foobar =
> Foo Foobar
I have a datatype with about a dozen constructors. I'd like to find a
way to use the type system to prevent one of the constructors from being
used in certain places. But I can't think of a way to do that.
data Foobar =
Foo Foobar |
Bar Foobar |
Zoo Foobar
I want the type system to t
G'day all.
Quoting Andrew Coppin <[EMAIL PROTECTED]>:
And yet they commonly pop up in Haskell. Can anybody put their finger
on precisely why that is?
One of the reasons why advanced type hackery shows up a lot in Haskell
is that Haskell has never taken the easy way out.
When confronted with
Hi Andrew,
Andrew Coppin wrote:
Haskell has an expressive and powerful type system - which I love. It
also has a seemingly endless list of weird and obscure type system
extensions. And there are various things you can do in Haskell which
*require* some pretty serious type system hackery.
And
Am Freitag, 14. März 2008 19:50 schrieb Andrew Coppin:
> […]
> Is it because Haskell is used by more PhDs? Is it because Haskell
> actually allows you to implement constructs that are impossible in other
> languages? Is it because Haskell really provides greater type safety? Is
> it something else
dpiponi:
> On Fri, Mar 14, 2008 at 11:50 AM, Andrew Coppin
> <[EMAIL PROTECTED]> wrote:
> > Haskell has an expressive and powerful type system - which I love. It
> > also has a seemingly endless list of weird and obscure type system
> > extensions...And yet, none of this happens in any other prog
On Fri, Mar 14, 2008 at 11:50 AM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> Haskell has an expressive and powerful type system - which I love. It
> also has a seemingly endless list of weird and obscure type system
> extensions...And yet, none of this happens in any other programming language
>
On Fri, Mar 14, 2008 at 2:50 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> Haskell has an expressive and powerful type system - which I love. It
> also has a seemingly endless list of weird and obscure type system
> extensions. And there are various things you can do in Haskell which
> *require
Haskell has an expressive and powerful type system - which I love. It
also has a seemingly endless list of weird and obscure type system
extensions. And there are various things you can do in Haskell which
*require* some pretty serious type system hackery.
And yet, none of this happens in any
On Tue, 08 Jan 2008 18:59:22 -0500, Achim Schneider <[EMAIL PROTECTED]> wrote:
Achim Schneider <[EMAIL PROTECTED]> wrote:
Prelude> let y f = f $ y f
Prelude> :t y
y :: (b -> b) -> b
Just out of curiosity: Where the heck does 'a' hide?
Beg pardon? Are you referring to the type of y being
Achim Schneider <[EMAIL PROTECTED]> wrote:
> Prelude> let y f = f $ y f
> Prelude> :t y
> y :: (b -> b) -> b
>
Just out of curiosity: Where the heck does 'a' hide?
--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthor
(The full code used for this message is available at
http://ryani.freeshell.org/haskell/systemf.hs)
System F is the polymorphically typed lambda calculus. It is strongly typed
but allows polymorphic functions like "id".
id is represented as follows:
> eId = EGamma "A" (ELam "x" TVar EVar)
whic
Hello Andrew,
Friday, July 13, 2007, 11:01:24 PM, you wrote:
>> definitely. for example, on windows it doesn't support unicode
>> filenames nor files bigger than 4gb
>> so i use my own lib, a thin layer around Windows API
> Has a bug been reported for this? Have you (or anyone else) thought
> a
Stefan O'Rear wrote:
On Fri, Jul 13, 2007 at 06:45:03PM -0400, Brandon S. Allbery KF8NH wrote:
On Jul 13, 2007, at 15:11 , Stefan O'Rear wrote:
There is no such thing as 8-bit ASCII - base assumes files contain
ISO-8859-1.
Hm, shouldn't it really be ISO-8859-15? (The difference
Jonathan Cast wrote:
On Friday 13 July 2007, Andrew Coppin wrote:
Stefan O'Rear wrote:
Try not to care what other people think.
LOL! If only that were in fact physically possible...
Why not? I do it all the time...
Clearly you don't know me... I spend 80% of my life
On Friday 13 July 2007, Andrew Coppin wrote:
> Stefan O'Rear wrote:
> > Don does not speak for the whole community, I for one am fine with
> > answering all these questions :)
>
> I guess when somebody as important as Don says something, you take
> notice...
>
> > Specifically, Don really wants you
andrewcoppin:
> Stefan O'Rear wrote:
> >On Fri, Jul 13, 2007 at 08:57:58PM +0100, Andrew Coppin wrote:
> >
> >>>- Join us on #haskell on IRC. It's extremely chatty, and you'll be
> >>>welcome.
> >>>
> >>Not in my experience, no.
> >>
> >>(Maybe I ask the wrong way... but almost everybody
On Fri, Jul 13, 2007 at 06:45:03PM -0400, Brandon S. Allbery KF8NH wrote:
>
> On Jul 13, 2007, at 15:11 , Stefan O'Rear wrote:
>
>> There is no such thing as 8-bit ASCII - base assumes files contain
>> ISO-8859-1.
>
> Hm, shouldn't it really be ISO-8859-15? (The difference being that -1
> predate
On Jul 13, 2007, at 15:11 , Stefan O'Rear wrote:
There is no such thing as 8-bit ASCII - base assumes files contain
ISO-8859-1.
Hm, shouldn't it really be ISO-8859-15? (The difference being that
-1 predates the euro symbol.)
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAI
Stefan O'Rear wrote:
On Fri, Jul 13, 2007 at 08:57:58PM +0100, Andrew Coppin wrote:
- Join us on #haskell on IRC. It's extremely chatty, and you'll be
welcome.
Not in my experience, no.
(Maybe I ask the wrong way... but almost everybody seems to simply ignore
me. Actually, usually
Stefan O'Rear wrote:
Don does not speak for the whole community, I for one am fine with
answering all these questions :)
I guess when somebody as important as Don says something, you take notice...
Specifically, Don really wants you to get off of the mailing list and
ask all these questio
On Fri, Jul 13, 2007 at 08:57:58PM +0100, Andrew Coppin wrote:
> Bryan O'Sullivan wrote:
>> Andrew Coppin wrote:
>>
>>> Oh well, the problem is easily fixed... *sigh*
>>
>> I doubt that anybody minds having you talk about Haskell. You've been
>> responsible for spawning a lot of interesting threa
Bryan O'Sullivan wrote:
Andrew Coppin wrote:
Oh well, the problem is easily fixed... *sigh*
I doubt that anybody minds having you talk about Haskell. You've been
responsible for spawning a lot of interesting threads.
[And that one about compression that's still going on somewhere... lol!]
Stefan O'Rear wrote:
On Fri, Jul 13, 2007 at 08:05:36PM +0100, Andrew Coppin wrote:
I was actually commenting on the other guy's remark that "anything that
chokes on a BOM can be considered buggy" - not entirely seriously. ;-)
If there is a "bug" to be reported, it is merely that [the GHC
i
On Fri, Jul 13, 2007 at 07:52:01PM +0100, Andrew Coppin wrote:
> Donald Bruce Stewart wrote:
>>
>> By the way Andrew, have you noticed that you're generating 50% of the
>> traffic on this list? Perhaps we can work a bit more on improving the
>> signal/noise ratio. My inbox can only take so much of
On Fri, Jul 13, 2007 at 08:05:36PM +0100, Andrew Coppin wrote:
> Ketil Malde wrote:
>> On Thu, 2007-07-12 at 19:15 +0100, Andrew Coppin wrote:
>>
>>
While BOMs (Byte Order Mark) are pretty irrelevant to byte-oriented
encodings like UTF-8, I think programs that fail on their presence ca
Ketil Malde wrote:
On Thu, 2007-07-12 at 19:15 +0100, Andrew Coppin wrote:
While BOMs (Byte Order Mark) are pretty irrelevant to byte-oriented
encodings like UTF-8, I think programs that fail on their presence can
be considered buggy.
Yay! Haskell's text I/O system is buggy. :-P
Bulat Ziganshin wrote:
Hello Andrew,
Yay! Haskell's text I/O system is buggy. :-P
definitely. for example, on windows it doesn't support unicode
filenames nor files bigger than 4gb
...OK, that's quite worrying...
so i use my own lib, a thin layer around Windows API
Has a bug
Donald Bruce Stewart wrote:
By the way Andrew, have you noticed that you're generating 50% of the
traffic on this list? Perhaps we can work a bit more on improving the
signal/noise ratio. My inbox can only take so much of this... ;)
o_O
My God... even the Haskell mailing list is complainin
On Fri, Jul 13, 2007 at 10:26:38AM +0200, Ketil Malde wrote:
> On Thu, 2007-07-12 at 19:15 +0100, Andrew Coppin wrote:
>
> > > While BOMs (Byte Order Mark) are pretty irrelevant to byte-oriented
> > > encodings like UTF-8, I think programs that fail on their presence can
> > > be considered buggy.
On Thu, 2007-07-12 at 19:15 +0100, Andrew Coppin wrote:
> > While BOMs (Byte Order Mark) are pretty irrelevant to byte-oriented
> > encodings like UTF-8, I think programs that fail on their presence can
> > be considered buggy.
> Yay! Haskell's text I/O system is buggy. :-P
Works for me, but fee
Hello Andrew,
Thursday, July 12, 2007, 10:15:00 PM, you wrote:
>> While BOMs (Byte Order Mark) are pretty irrelevant to byte-oriented
>> encodings like UTF-8, I think programs that fail on their presence can
>> be considered buggy.
>>
> Yay! Haskell's text I/O system is buggy. :-P
definitely.
On Jul 12, 2007, at 20:48 , Donald Bruce Stewart wrote:
By the way Andrew, have you noticed that you're generating 50% of the
traffic on this list? Perhaps we can work a bit more on improving the
signal/noise ratio. My inbox can only take so much of this... ;)
I can blather more, if you'd lik
andrewcoppin:
> Ketil Malde wrote:
> >On Wed, 2007-07-11 at 20:10 +0100, Andrew Coppin wrote:
> >
> >
> >>When I tell the editor to save UTF-8, it inserts some weird "BOM"
> >>character at the start of the file - and thus, any attempt at
> >>programatically processing that file instantly fails.
On Thu, Jul 12, 2007 at 04:58:43PM -0400, Steve Schafer wrote:
On Thu, 12 Jul 2007 21:24:24 +0100, you wrote:
Given that (IIRC) the BOM is just a valid unicode non-breaking space,
your scripts really ought to cope...
Choking on the BOM is probably just a symptom of a deeper problem. My
bet is
On Thu, 12 Jul 2007 21:24:24 +0100, you wrote:
>Given that (IIRC) the BOM is just a valid unicode non-breaking space,
>your scripts really ought to cope...
Choking on the BOM is probably just a symptom of a deeper problem. My
bet is that removing the BOM would simply delay the failure until the
f
On Thu, Jul 12, 2007 at 09:24:24PM +0100, Philip Armstrong wrote:
On Thu, Jul 12, 2007 at 07:01:31PM +0100, Andrew Coppin wrote:
Let me put it this way: It makes all my Tcl scripts stop working, and it
makes my Haskell-based processor go nuts too...
Given that (IIRC) the BOM is just a valid un
On Thu, Jul 12, 2007 at 07:01:31PM +0100, Andrew Coppin wrote:
Let me put it this way: It makes all my Tcl scripts stop working, and it
makes my Haskell-based processor go nuts too...
Given that (IIRC) the BOM is just a valid unicode non-breaking space,
your scripts really ought to cope...
Phi
Ketil Malde wrote:
On Wed, 2007-07-11 at 20:10 +0100, Andrew Coppin wrote:
When I tell the editor to save UTF-8, it inserts some weird "BOM"
character at the start of the file - and thus, any attempt at
programatically processing that file instantly fails. :-(
While BOMs (Byte Order
Albert Y. C. Lai wrote:
Andrew Coppin wrote:
When I tell the editor to save UTF-8, it inserts some weird "BOM"
character at the start of the file - and thus, any attempt at
programatically processing that file instantly fails. :-(
I know Windows Notepad puts a BOM at the beginning of UTF-8 fi
On Thu, 12 Jul 2007, Stefan O'Rear wrote:
> On Thu, Jul 12, 2007 at 09:12:14AM +0200, Henning Thielemann wrote:
> >
> > On Tue, 10 Jul 2007, Jonathan Cast wrote:
> >
> > > On Tuesday 10 July 2007, Andrew Coppin wrote:
> > > > Stefan O'Rear wrote:
> > >
> > > > > Consider the ST monad, which lets
On Wed, 2007-07-11 at 20:10 +0100, Andrew Coppin wrote:
> When I tell the editor to save UTF-8, it inserts some weird "BOM"
> character at the start of the file - and thus, any attempt at
> programatically processing that file instantly fails. :-(
While BOMs (Byte Order Mark) are pretty irrelev
On Thursday 12 July 2007, Henning Thielemann wrote:
> On Tue, 10 Jul 2007, Albert Y. C. Lai wrote:
> > Andrew Coppin wrote:
> > > Wait... I thought Unicode was still an experimental prototype? Since
> > > when does it work in the real world??
> >
> > That myth is as old as "Haskell is an experiment
On Thu, Jul 12, 2007 at 09:12:14AM +0200, Henning Thielemann wrote:
>
> On Tue, 10 Jul 2007, Jonathan Cast wrote:
>
> > On Tuesday 10 July 2007, Andrew Coppin wrote:
> > > Stefan O'Rear wrote:
> >
> > > > Consider the ST monad, which lets you use update-in-place, but is
> > > > escapable (unlike
On Tue, 10 Jul 2007, Albert Y. C. Lai wrote:
> Andrew Coppin wrote:
> > Wait... I thought Unicode was still an experimental prototype? Since
> > when does it work in the real world??
>
> That myth is as old as "Haskell is an experimental prototype". "Old" as
> in "that's an old one".
>
> Windows
On Tue, 10 Jul 2007, Jonathan Cast wrote:
> On Tuesday 10 July 2007, Andrew Coppin wrote:
> > Stefan O'Rear wrote:
>
> > > Consider the ST monad, which lets you use update-in-place, but is
> > > escapable (unlike IO). ST actions have the form:
> > >
> > > ST s α
> > >
> > > Meaning that they ret
On Jul 11, 2007, at 18:52 , Albert Y. C. Lai wrote:
Brandon S. Allbery KF8NH wrote:
GNOME's gedit, for one, has a tendency to put byte order marks at
the beginning of every line in UTF8 mode.
Somehow I have never got a single BOM. My http://www.vex.net/
~trebla/u.html was written out by GN
Brandon S. Allbery KF8NH wrote:
GNOME's gedit, for one, has a tendency to put byte order marks at the
beginning of every line in UTF8 mode.
Somehow I have never got a single BOM. My
http://www.vex.net/~trebla/u.html was written out by GNOME gedit.
Version 2.14.4.
On Jul 11, 2007, at 15:23 , Alex Queiroz wrote:
On 7/11/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
When I tell the editor to save UTF-8, it inserts some weird "BOM"
character at the start of the file - and thus, any attempt at
programatically processing that file instantly fails. :-(
1 - 100 of 139 matches
Mail list logo
