Re: Multiple imports on a single line

[Jon Fairbairn]

Sven Panne 
writes:

> I often see a confusion between greater expresiveness (good goal) and
> having to type less (largely irrelevant goal). By all means make the module
> system more expressive, but try to avoid "clever" things for convenience.

+1

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

[Jon Fairbairn]

Alexander Berntsen
 writes:
> [ Foo
> , Bar
> , Fu
> , Baz ]
>
> It is impossible to remove values Foo or Baz with a one line diff. It
> is additionally impossible to reasonably add a new value to the top or
> bottom of the list.

I’m not on the committee either, but here’s my three haporth.

Something that is missing from this type of discussion is any
reference to design rules, agreement on which should be made
before any suggestion like this.

The one this violates is “never make language design decisions
to work around deficiencies in tools” The problem is that diff
does its work in ignorance of the syntax and consequently
produces poor results.

The other observation I want to make is that the object of
programming language design is not to make writing programmes
(or changing) easier. It is to make writing incorrect programmes
(especially programmes that look right but are not) harder. We
have to ask whether making a “one line diff” do this is actually
productive. Having a large Hamming distance between
syntactically valid programmes is an advantage.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: definition of List.transpose

[Jon Fairbairn]

Doug McIlroy d...@cs.dartmouth.edu
writes:

 Not having participated in haskell' before, I'm not sure how
 to put these perfecting amendments--mot langauge changes--into
 the pot.

You might want to try the libraries list rather than Haskell
prime for this sort of thing.

  ― Jón

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: [Haskell-cafe] Why are field selectors functions?

[Jon Fairbairn]

AntC anthony_clay...@clear.net.nz writes:

 No! This isn't more bikeshedding about notation.

 It's a bit of Haskell archaeology.

 On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson wrote:
 [This isn't exactly what Judah wrote.]
 ...

 Instead of `x f` (to access field x of record f),
 maybe we could write `f{x}` as the record selection.  


 The more I thought about that ...

 We use { ... } to declare records, build them, update them.
 We use { ... } in pattern matching to access named fields.

 Why don't we use { ... } to access named fields in terms?

 The syntax `e{ foo }` is unused in H98. (Or at least it was in 1998.)
 Can someone who was there at the time (1994?, TRex?)
 remember if that was ever considered?

No one else has answered (at least in café), but perhaps the
reason is that like me they can’t really remember! I do remember
that since Haskell is a functional language we wanted as many
things to be functions as possible; we did want to be able to
pass field selectors around as arguments to other functions.

I vaguely remember suggesting some years later that we should
have {…} being a function, so that {field} is a field selector
and {field=value} is a field setter (and requiring that you had
to write use normal function application: “{field} structure” to
select field from structure). SimonPJ gave a reason why not, and
I’m sure it will be possible to search out what he said.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Proposal: Non-recursive let

[Jon Fairbairn]

Andreas Abel
andreas.a...@ifi.lmu.de writes:

 Proposal: add a non-recursive let to the Haskell language.  In

   let' p = e in e'
   do { ... let' p = e ... }

 the variables of pattern p are then *not* in scope in e.

 Reasons for adding a non-recursive let:

 1. recursive-let is the source for many non-termination bugs.

-1 from me. I don’t see that having non-recursive let available
will have much impact on the bugs. It just changes forgetting to
use different variable names because of recursion (which is
currently uniform throughout the language) to forgetting to use
non recursive let instead of let.
-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: [Haskell-cafe] Lambda Calculus question on equivalence

[Jon Fairbairn]

Francesco Mazzoli f...@mazzo.li writes:

 At Fri, 03 May 2013 16:34:28 +0200,
 Andreas Abel wrote:
 The answer to your question is given in Boehm's theorem, and the answer 
 is no, as you suspect.
 
 For the untyped lambda-calculus, alpha-equivalence of beta-eta normal 
 forms is the same as observational equivalence.  Or put the other way 
 round, two normal forms which are not alpha-equivalent can be separated 
 by an observation L.

 Thanks for the reference, and sorry to Ian for the confusion given by the fact
 that I was thinking in types...

 However, what is the notion of ‘telling apart’ here exactly?  Is it simply 
 that
 the resulting terms will have different denotations in some semantics?  My
 initial (wrong) assumption about termination was due to the fact that I 
 thought
 that the ultimate test of equivalence was to be done with α-equivalence 
 itself,
 on the normal forms.

α-equivalence on the Böhm trees — normal forms extended to
infinity. I suppose that counts as “some semantics” but its very
direct.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Prolog-style patterns

[Jon Fairbairn]

Jan Stolarek jan.stola...@p.lodz.pl writes:

 Hi all,

 consider this simple reimplementation of 'elem' function:

 member :: Eq a = a - [a] - Bool
 member _ [] = False
 member y (x:xs) | x == y= True
 | otherwise = member y xs

 If Haskell allowed to write pattern matching similar to Prolog then we could 
 write this function 
 like this:

 member :: Eq a = a - [a] - Bool
 member _ [] = False
 member x (x:_)  = True
 member x (_:xs) = member x xs

This kind of pattern matching was considered and rejected by the
very first Haskell committee. Others have given some of the
reasoning, and I don’t recall the rest so won’t attempt to
rehearse them here. What I would like to say (without meaning to
attack you personally, Jan) is that we really need to make a
rule that this sort of small convenience should never be
considered.

Every now and a language feature will be invented that really
makes a large difference to a large number of programmes (do
notation was a prime example), so the language should evolve.
But against that, there is considerable value in having the
basic syntax remain unchanged for as long as possible.

I don’t know how to formulate it formally, but the rule should
be something like, unless a new feature shortens programmes that
can use it by a significant factor, it shouldn’t be included.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ticking time bomb

[Jon Fairbairn]

Marc Weber marco-owe...@gmx.de writes:

 The only safe way is acceptnig keys from people you know don't view pdf
 using adobe reader,

I don’t…

 who don't browse the web (neither use flash) etc.

I only browse the web (in general) from a diskless virtual
machine.

 And then still you also have to know that their email account password
 is reasonable strong ..

I don’t think you need to know that: you need to know that their
signing key password is strong, that they’ve never entered it
into a machine with a keylogger running, and no-one has shoulder
surfed them. Oh, and that no-one can blackmail or torture them
:-P

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Country names and language names

[Jon Fairbairn]

Henk-Jan van Tuyl hjgt...@chello.nl writes:

 On Wed, 06 Mar 2013 20:53:57 +0100, Obscaenvs obscae...@gmail.com wrote:
 Do not forget that country names can change; e.g. the Netherlands
 Antilles were split up in 2010. This might cause problems if you store
 country codes in a database. If you simply remove obsolete country
 codes, the database can not be used properly any more.

 P.S. If you want people to be able to enter there country of
 birth, you should include all countries that existed in the
 past 116 years; if  historians should be able to use it, you
 should include all countries that  ever existed.

These are both important points, but I think they fall outside
the remit of a library for ISO 3166 country codes, which I wrote
originally for use in circumstances where some other standard
just says “an ISO 3166 country code”. If the country codes
standard included (as ISO 639 language codes does) historical
codes, it would be appropriate to include them in that library,
but since it doesn’t, it requires a separate library.

Quite how far one should go back in this separate library I
cannot say, but there are obvious use cases for country /names/
for countries that ceased to exist before 1974 and which
therefore have never had an ISO 3166 country code.


* * *

I’m currently working on ISO 639 which again will be a
presentation of the standard as Haskell data types. It requires
ISO 15924 Script codes. It’s irritating how these things have
been standardised: the registry for ISO 639 is a different
format from ISO 15924, and the former includes (presumably
non-normatively) records for the script codes. In 639 ranges are
specified with “..” but in 15924 they are simply mentioned in
the names :-(.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2012-10-07)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to input Unicode string in Haskell program?

[Jon Fairbairn]

Alexander V Vershilov alexander.vershi...@gmail.com writes:

 The problem is that Prelude.getLine uses current locale to load characters:
 for example if you have utf8 locale, then everything works out of the box:

 $ runhaskell 1.hs
 résumé 履歴書 резюме
 résumé 履歴書 резюме

 But if you change locale you'll have error:

 LANG=C runhaskell 1.hs
 résumé 履歴書 резюме
 1.hs: stdin: hGetLine: invalid argument (invalid byte sequence)

That seems to be correct behaviour: the only way to know the
meaning of the bits input by a user is what encoding the user
says they are in.

But in general this issue is an instance of inheriting sins from
the OS: the meaning of the bit pattern in a file should be part
of the file, but we are stuck with OSs that use a global
variable (which should be anathema to Haskell). So if user A has
locale set one way and inputs a file and sends the filename to
user B on the same system, user B might well see something
completely different to A when looking at the file.

 To force haskell use UTF8 you can load string as byte sequence
 and convert it to UTF-8 charecters

but of course, the programmer can only hope that utf-8 will work
here. If the user is typing in KOI-8R, reading it as utf-8 is
going to be wrong.
-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why isn't Program Derivation a first class citizen?

[Jon Fairbairn]

Rustom Mody rustompm...@gmail.com writes:

 On Wed, Feb 13, 2013 at 4:17 AM, Nehal Patel nehal.a...@gmail.com wrote:
 
 Why isn't Program Derivation a first class citizen?
 ---
 I am stating these things from somewhat foggy memory (dont have any
 lambda-calculus texts handy) and so will welcome corrections from those who
 know better…

 In lambda-calculus, if reduction means beta-reduction, then equality is

semi

 decidable

 If a theorem-prover were as 'hands-free' as a programming language
 Or if an implemented programming language could do the proving that a
 theorem-prover could do, it would contradict the halting-problem/Rice
 theorem.

Just so, but I’ve long (I suggested something of the sort to a
PhD student in about 1991 but he wasn’t interested) thought
that, since automatic programme transformation isn’t going to
work (for the reason you give), having manually written
programme tranformations as part of the code would be a useful
way of coding. RULES pragmas go a little way towards this, but
the idea would be that the language supply various known valid
transformation operators (akin to theorem proving such as in
HOL), and programmers would explicitly write transformation for
their functions that the compiler would apply.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: lambda case

[Jon Fairbairn]

Brent Yorgey byor...@seas.upenn.edu writes:

 Oh, PLEASE people.  Let's not have another round of bikeshedding about
 this AFTER the feature is already implemented!

This is not an argument about the colour of the bikeshed. In
terms of that analogy, this has gone something like this:

Someone says the bikeshed doorknob is hard to turn and we should
have a handle. There’s some discussion, I say maybe, but lets
not do it unless we have a good design. Someone else comes up
with the beginnings of a good design for a handle, but there’s
no consensus about that and it all goes quiet. Some time later a
voice says that if nobody does anything it’ll get forgotten
(which is what I was hoping would happen). I repeat that it’s
better not to do it without a good design and nod off. When I
wake up, a handle has been installed by hot-melt glueing a bit
of rough sawn timber to the doorknob. I complain. Another voice
tells me to shut up, we’ve done it now.

  — Jón


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] lambda case

[Jon Fairbairn]

Brandon Allbery allber...@gmail.com writes:

 On Sat, Dec 1, 2012 at 5:30 AM, Roman Cheplyaka r...@ro-che.info wrote:

 I find this discussion useful — there are some interesting points
 (splitting case of into two parts) that I don't remember reading in the
 original thread (but maybe it's just me).


 Mentioned twice that I recall, as treating 'of' as a lambda and as '\of'.

I’m not quite sure what treating “of” as lambda means, and \of
raises the some of the same objections as \case.

Up until the introduction of “lambda-case”, \ was a clear
indication that what was coming next was a pattern that would
bind variables (except in degenerate cases, but anyone who
writes something like \Nothing - e should be taken out and sho-
wn why it’s a bad idea).

  It got somewhat short shrift, likely because while it makes sense from an
 existing language syntax viewpoint, it makes little to none from a
 readability standpoint.

Of the available alternatives, it makes the most linguistic
sense. If you can’t read the subtext for that sentence, try
again :-) In the design I was suggesting, “of” is in no sense a
lambda, it simply introduces a list of alternative patterns
exactly as it does in the original design of case … of {alts}.
Arguing about whether “of” is the right keyword here without
arguing that case… of… should have different keywords is
inconsistent, and arguing for a change of those keywords really
would be fussing about the colour of the bikeshed after it was
painted.


-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] lambda case

[Jon Fairbairn]

Andreas Abel andreas.a...@ifi.lmu.de writes:

 I had been missing a pattern matching lambda in Haskell for
 a long time (SML had fn since ages) and my typical use
 will be

   monadic_expr = \case
 branches

We’ve been through that.  I want something similar, but would
have preferred something more algebraic.

 I think \case is not the worst choice, certainly better than
 of ...

What’s your argument? You’ll have to do better than blatant
assertion to convince me. Making “case exp” optional builds on
an existing expression syntax, giving an explicit meaning to a
part of it, so a reader only has to know that “of {alts}” is a
function and case does something specific with it. This “\case”
takes the keyword from that expression syntax and makes it a
special case of lambda, so a reader seeing a lambda now has to
check for a keyword instead of knowing straight off that the
next thing is going to be a variable.

Back when we originally designed Haskell there were lots of
things that people wanted to put in, and eventually we reached a
point where we said that we would only put something new in if
it allowed us to remove (or simplify) something else. “\case”
complicates lambda, using “of” simply breaks “case … of …” into
two easily understood parts.
-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Jon Fairbairn]

Ben Franksen ben.frank...@online.de writes:

 just wanted to drop by to say how much I like the new lambda case extension. 
 I use it all the time and I just *love* how it relieves me from conjuring up 
 dummy variables, which makes teh code not only esier to write but also to 
 read.

 […] should *definitely* go into Haskell'13.

As I was opposed to the suggestion for lambda case I didn’t
really follow the discussion of the syntax, but I’m puzzled by
the choice. To me it seems obvious that if we are going to do
this (as opposed to something more decomposable like
lambda-match), we should do it simply by making the “case exp”
part of a case expression optional. So the syntax for lambda-
case would be

   of {alts…}

and we would then describe

   case e of {…}

as syntactic sugar for

   (of {…}) (e)

Doing it this way doesn’t introduce any new syntactic elements
and has fewer tokens at the point of use.

I don’t see any need for a \ in the syntax: this is a functional
language we are talking about after all. Once we know that “of”
introduces a function, that should be enough.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Sparse records/ADTs

[Jon Fairbairn]

Yuri de Wit yde...@gmail.com writes:

 Would this be relevant?

 https://github.com/jonsterling/Data.Records

That looks promising, thanks.  It does use rather a lot of
extensions, so it’ll take me a while to understand it.
-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Sparse records/ADTs

[Jon Fairbairn]

Twan van Laarhoven twa...@gmail.com writes:

 On 24/10/12 12:08, Jon Fairbairn wrote:

 Is there a convenient way of handling a data structure with lots
 of fields of different types that may or may not be filled in?


 Not sure about convenience, but here is a type safe solution
 with O(log n) lookups and updates. The idea is to define a
 GADT tree type with a fixed layout:

Thanks for your reply (and for all the others). Since type safe
is something that (for me) goes without saying, this is the best
solution, but it doesn’t really satisfy the convenience aspect.
(I had already looked at solutions using Map and contemplated a
tree structure, but didn’t like anything I had come up with). In
short, it looks like the answer to my question is “No.” :-/

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Sparse records/ADTs

[Jon Fairbairn]

Is there a convenient way of handling a data structure with lots
of fields of different types that may or may not be filled in?

Something equivalent to

data D = D {a::Maybe A, b::Maybe B, c::Maybe C, …}

but with better space efficiency and a more convenient empty
object.

An easy alternative is

data E = Ea A | Eb B | Ec C | …
type R = [E]

which has a straightforward empty object, but one then must
define

   getA e = listToMaybe [a | Ea a - e]

for each field, which is tedious (and O(n)). Obviously Templates
would help, but is there an alternative I’ve missed?

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monads

[Jon Fairbairn]

Albert Y. C. Lai tre...@vex.net writes:

 On 12-09-30 06:33 PM, Jake McArthur wrote:
 When discussing monads, at least, a side effect is an effect that is
 triggered by merely evaluating an expression. A monad is an interface
 that decouples effects from evaluation.

 I don't understand that definition. Or maybe I do subconsciously.

 I have

 s :: State Int ()
 s = do { x - get; put (x+1) }

 Is there an effect triggered by merely evaluating s?

 I have

 m :: IO ()
 m = if True then putStrLn x else putChar 'y'

 Is there an effect triggered by merely evaluating m?

 What counts as evaluate?

Evaluation! Consider m `seq` 42. m is evaluated, but to no
effect.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to take a minimum sub list that only contain certain number of elements of certain type?

[Jon Fairbairn]

Magicloud Magiclouds magicloud.magiclo...@gmail.com writes:

 Hi,
   For example, I have an array [0..]. Now I want to take a sub list
 that starts from index 0, and only contain 4 odds, and is minimum
 result. The answer should be [0, 1, 2, 3, 4, 5, 6, 7].
   How to do that? Combining lazy computing, I cannot figure out an
 efficient algorithm.

Does

f bound odds_so_far [] = []
f bound odds_so_far (x:xs)
 | odds_so_far == bound = []
 | otherwise = x : f bound (odds_so_far + if odd x then 1 else 0) xs

required_funciton = f 4 0

meet your criteria, or am I missing something?

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Knight Capital debacle and software correctness

[Jon Fairbairn]

Jay Sulzberger j...@panix.com writes:

 On Sat, 4 Aug 2012, Clark Gaebel cgae...@uwaterloo.ca wrote:

 As far as I know, you can't check equivalence of _|_. Since Haskell uses
 _|_ to represent a nonterminating computation, this would be
 synonymouswith solving the halting
 problem.

 Ah, thanks.  I will attempt to think about this.

Also, one way of looking at type systems says that all these
_|_s are the same (but as Clark says, there’s no way within
Haskell to compare them). Haskell mangles this a little by
including non-value things other than non-termination in its
types.

   — Jón


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Call to arms: lambda-case is stuck and needs your help

[Jon Fairbairn]

Mikhail Vorozhtsov mikhail.vorozht...@gmail.com writes:

 Hi.

 After 21 months of occasional arguing the lambda-case
 proposal(s) is in danger of being buried under its own trac
 ticket comments. We need fresh blood to finally reach an
 agreement on the syntax. Read the wiki page[1], take a look
 at the ticket[2], vote and comment on the proposals!

 P.S. I'm CC-ing Cafe to attract more people, but please keep
 the discussion to the GHC Users list.

 [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching
 [2] http://hackage.haskell.org/trac/ghc/ticket/4359

Apart from lambda match, the suggestions seem to me to be poor
solutions to an old piece of bad design and they don’t fit very
well with the look of haskell.

Way back at the beginning of time, I was against pattern
matching altogether as it seemed like a seductive feature that
wouldn’t generalise very well. I wanted algebraic combinations
of some form of guarded expressions. But the rest of the
committee wanted pattern matching (I think they were right — the
seductive aspect is important and if I had had my way Haskell
would not have been as popular as it is now) and it seemed
logical to have pattern matching in lambdas too. But that led to
lambdas that can fail, which I think was a bad decision.

What I would rather have happen now is that we introduce a
distinction between pure destructor patterns (where a type is
not a sum) and patterns that can fail. Then mandate that at some
future date \pattern1 - expression will be invalid unless
pattern1 is a pure destructor, (but to begin with the compiler
would just issue a warning). Now \pattern1 - expression has
type a - b without a hidden exception.

Then add another lambda for patterns that can fail, eg \?
pattern - expression, which has a type reflecting the fact that
the match can fail, eg a - Maybe b. Add operators to combine
such lambda expressions (eg a symbol — on the lines of || — for
liftA2 mplus) and a means of getting the answer out when all the
bases are covered (something a bit handier than just having an
operator for liftA2 fromMaybe, though that would cover all the
use cases that end with \? _ - e).

lambda match is very close to that and worked out in more
detail. So I’m against the other proposals.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell-cafe] Failing to find a function

[Jon Fairbairn]

This is probably a failure of my search fu or some other mental
lacuna, but is there already a definition of this function
somewhere:

\a b - runKleisli $ (Kleisli a) + Kleisli b
?

Hoogling for its type

   MonadPlus m = (a - m b) - (a - m b) - a - m b

doesn’t net me anything useful.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Failing to find a function

[Jon Fairbairn]

Erik Hesselink hessel...@gmail.com writes:
 On Sun, Feb 19, 2012 at 12:50, Jon Fairbairn jon.fairba...@cl.cam.ac.uk 
 wrote:
 This is probably a failure of my search fu or some other mental
 lacuna, but is there already a definition of this function
 somewhere:

 \a b - runKleisli $ (Kleisli a) + Kleisli b
 ?

 Not a single name, but I believe

   liftA2 mplus

 is the same function, and much shorter (and more general).

That’s the ticket. I was sure there was something like that (and
I almost asked if there was a library function g such that g
mplus = …).

Thanks,

  — Jón


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Rewrite this imperative in FP way

[Jon Fairbairn]

Haisheng Wu fre...@gmail.com writes:

 a = [1,1,1,1]
 b = [0,1,2,3]
 d = [0,0,0,0]

 for i in b:
   for j in c:
 if (i+j)3:
   d[i+j] += a[i]
 Do you have any cool solution in FP way?

I find the above sufficiently alien that I can’t work out what
it’s meant to do (what is it actually for?). c is undefined for
one thing. But you might like to see what 

do i - b; j -c ; return (i,j)

does and consider what “filter ( 3) . map (uncurry (+))”
does, and possibly look at Data.Array.array, depending on what
the problem you are trying to solve is.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] strict, lazy, non-strict, eager

[Jon Fairbairn]

(I’m somewhat dismayed that the error in my preliminary remark
has overshadowed the point of my original message — which was
about the distinction between lazy and non-strict. However…)

David Barbour dmbarb...@gmail.com writes:
 Full beta-reduction is certainly not strict

What, precisely, do you mean by “full beta-reduction”?

 but also doesn't guarantee terminate even where it is possible
 (i.e. it might indefinitely unfold a value without making
 progress).

That sounds very much to me like being overly strict.

 I don't think there is much you can say about non-strictness
 and termination.

I would hope there would be, as that (or at least productivity)
is the point of saying that Haskell has non-strict semantics.

 On Mon, Jan 9, 2012 at 3:01 AM,
 Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote:

 Perhaps what I should have said to be almost as succinct but
 this time accurate is “non-strict semantics requires that the
 evaluation strategy terminate if there is any evaluation
 strategy that terminates”?

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] strict, lazy, non-strict, eager

[Jon Fairbairn]

wren ng thornton w...@freegeek.org writes:

 On 12/28/11 10:23 AM, Jon Fairbairn wrote:
 Thiago Negrievoh...@gmail.com  writes:

 Lazy evaluation is one implementation of non-strict semantics, where
 the arguments are evaluated only when they are needed.

 I would say this:

 * non-strict semantics require that no argument is evaluated
unless needed.

 I'm not sure that's quite right.

I’m sure it’s not right (as was pointed out a while ago). I was
in too much of a hurry to get to the next bit, namely giving a
description of the difference between non-strict and lazy.
Perhaps what I should have said to be almost as succinct but
this time accurate is “non-strict semantics requires that the
evaluation strategy terminate if there is any evaluation
strategy that terminates”?


-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to split this string.

[Jon Fairbairn]

Steve Horne sh006d3...@blueyonder.co.uk writes:

 On 05/01/2012 11:09, Brandon Allbery wrote:
 On Thu, Jan 5, 2012 at 05:57, Steve Horne
 sh006d3...@blueyonder.co.uk
 mailto:sh006d3...@blueyonder.co.uk wrote:

  --  groupCut - Similar to groupBy, but where groupBy assumes an
 equivalence relation,
  --  groupCut takes a function that indicates where to cut. The
 two parameters to this
  --  function are always adjacent items from the list, and if the
 function returns True,
  --  a cut is done between the two items.

 span/break?

 Using those, the test function won't always be passed two
 *adjacent* elements from the list. After all, they're based
 on takeWhile and dropWhile, which take unary functions,
 meaning an element has already been curried in (the starting
 element of the group).

 That's probably how the current groupBy is implemented - the
 approach that assumes an equivalence relation, giving
 unexpected results when the By function isn't an equivalence
 relation.

groupBy is currently implemented using span.

It strikes me that we ought to specify some properties for what
we want. Start by defining:

   pairwiseInOrderBy p l = all (uncurry p) (l `zip` drop 1 l)

giving

   all (pairwiseInOrderBy p) (groupCut p l)

and we would want

   concat (groupCut p l) == l

(all modulo nontermination side conditions). Anything else?

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to split this string.

[Jon Fairbairn]

Steve Horne sh006d3...@blueyonder.co.uk writes:

 On 02/01/2012 11:12, Jon Fairbairn wrote:
 maxm...@mtw.ru  writes:

 I want to write a function whose behavior is as follows:

 foo string1\nstring2\r\nstring3\nstring4 = [string1,
 string2\r\nstring3, string4]

 Note the sequence \r\n, which is ignored. How can I do this?
 cabal install split

 then do something like

 import Data.List (groupBy)
 import Data.List.Split (splitOn)

 rn '\r' '\n' = True
 rn _ _ = False

 required_function = fmap concat . splitOn [\n] . groupBy rn

 (though that might be an abuse of groupBy)

 Sadly, it turns out that not only is this an abuse of
 groupBy, but it has (I think) a subtle bug as a result.

It does indeed. Thanks. That was pretty much what I feared.

 Explanation (best guess) - the function passed to groupBy,
 according to the docs, is meant to test whether two values
 are 'equal'. I'm guessing the assumption is that the
 function will effectively treat values as belonging to
 equivalence classes. That implies some rules such as...

Right.  This issue has come up from time to time since groupBy
was first written, and someone pops up to justify the present
behaviour, but I can never remember why.

 In the context of this \r\n test function, this behaviour
 will I guess result in \r\n\n being combined into one group.
 The second \n will therefore not be seen as a valid
 splitting point.

Correct. In my defence, I did say “do something like” :-)

 Personally, I think this is a tad disappointing. Given that
 groupBy cannot check or enforce that it's test respects
 equivalence classes, it should ideally give results that
 make as much sense as possible either way. That said, even
 if the test was always given adjacent elements, there's
 still room for a different order of processing the list
 (left-to-right or right-to-left) to give different results -
 and in any case, maybe it's more efficient the way it is.

Looking back at the libraries list, I get the impression that
there was a suggestion to change the behaviour of groupBy, but
it doesn’t seem to have happened.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2010-09-14)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to split this string.

[Jon Fairbairn]

max m...@mtw.ru writes:

 I want to write a function whose behavior is as follows:

 foo string1\nstring2\r\nstring3\nstring4 = [string1,
 string2\r\nstring3, string4]

 Note the sequence \r\n, which is ignored. How can I do this?

cabal install split

then do something like

   import Data.List (groupBy)
   import Data.List.Split (splitOn)

   rn '\r' '\n' = True
   rn _ _ = False

   required_function = fmap concat . splitOn [\n] . groupBy rn

(though that might be an abuse of groupBy)

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] strict, lazy, non-strict, eager

[Jon Fairbairn]

Thiago Negri evoh...@gmail.com writes:

 Lazy evaluation is one implementation of non-strict semantics, where
 the arguments are evaluated only when they are needed.

I would say this:

* non-strict semantics require that no argument is evaluated
  unless needed.

* lazy evaluation is an implementation of non-strict semantics
  in which no argument is evaluated more than once.

As an example of something other than lazy, normal order
reduction is non-strict, but arguments may be evaluated multiple
times.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] strict, lazy, non-strict, eager

[Jon Fairbairn]

Thiago Negri evoh...@gmail.com writes:

 2011/12/28 Jon Fairbairn jon.fairba...@cl.cam.ac.uk:
 * non-strict semantics require that no argument is evaluated
  unless needed.

 That's not the case on optimistic evaluation.

Oops, yes.  I should have said something like “non-strict
semantics require that evaluation should terminate if there is a
terminating reduction order” but went for something snappier
(and missed).

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2010-09-14)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Overloaded Strings as default

[Jon Fairbairn]

Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes:

 On 29 November 2011 07:28, Daniel Díaz Casanueva dhelta.d...@gmail.com 
 wrote:
 Hi Cafe,

 I only feel curious about what would be the consequences of becoming the
 Overloaded Strings feature (currently, an extension) to be default in
 Haskell. This is not a proposal. I just want to know what pros and
 cons there are.

 One cons would be that you may need some more explicit type signatures
 being used: I have the situation in my graphviz library where both
 Text and String have instances of some classes (e.g. Labellable, which
 has a method toLabel :: (Labellable a) = a - Label) which result in
 explicit String values in the source code result in the compiler not
 knowing which instance to use (e.g. toLabel hi).

Though that could be ameliorated by allowing defaulting with a
default default (if you will) of String.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] XML modification

[Jon Fairbairn]

Andrew Coppin andrewcop...@btinternet.com writes:

 On 23/11/2011 12:58 PM, Andrew Coppin wrote:
 On 23/11/2011 10:14 AM, Jon Fairbairn wrote:
 HaXml

 Mmm. That looks very promising...

 which gives some idea of the flavour.

 OK. So it looks like processXmlWith is the function I want, if I'm going
 to read one file and create another from it. So now I just need to
 figure out which combinators I need. (The documentation seems a bit
 thin.) Can you show me a snippet for how I would find [one] element
 named foo and change its bar attribute to have the value 5?

 Well, from what I've been able to gather, HaXml has a really
 nice filter combinator library. However...

 Weird thing #1: processXmlWith handles the common case of
 loading a file from disk, filtering it, and saving the
 result to disk again. However, it does this based on CLI
 arguments. There is no function anywhere that I can find
 which allows the host program to specify what files to
 process. If you want to do that, you have to reimplement
 most of the body of this function all over again yourself.
 That seems a strange omission.

 Weird thing #2: There are absolutely no filters for dealing
 with attributes. I couldn't find anything anywhere that says
 apply this function to all the attributes of this element.
 I can find a function to /replace/ an element's attributes
 without regard to what existed before. But even something as
 trivial as adding an additional attribute while keeping the
 existing ones doesn't appear to be supported at all.

 Fortunately it turns out to not be especially hard to read
 the source for the replace-attributes function and change it
 to do what I want. But, again, it seems a rather large and
 obvious ommission. (I'm guessing that since attributes are
 key/value pairs and not content, you would need a seperate
 attribute filter type, which is different from the
 existing content filters. Even so, it shouldn't be /that/
 hard to do...)

 Anyway, the important thing is, Haskell (and more
 specifically HaXml) let me accomplish the task I wanted
 without too much fuss. It's /certainly/ faster than editing
 80 files by hand in a text editor!

I think these observations should be addressed to Malcolm
Wallace.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] XML modification

[Jon Fairbairn]

Andrew Coppin andrewcop...@btinternet.com writes:

 I've got a folder with about 80 XML files in it. I want to
 take each file and make specific modifications to it.
 (Mostly just finding specific attributes and changing their
 values to make then all consistent.)

 Now I guess it wouldn't take me /that/ long to code
 something from scratch. But does anybody have a better
 suggestion for tools or libraries that might be useful?

HaXml

Before google earth exposed a facility for computing path
lengths, I wrote my own using HaXml. The guts of it look like
this:

main …
 xml - fmap (xmlParse filename) (readFile filename)
 print_path_length xml

print_path_length (Document _ _ content _)
= print $ compute_length $ coordinate_string_to_list coordinate_string
  where coordinate_string
= singleCString
  . (txt `o` children `o` deep (tag coordinates))
  $ (CElem content)

which gives some idea of the flavour.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2010-09-14)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Solving the configuration problem with parametrized modules

[Jon Fairbairn]

Joachim Breitner m...@joachim-breitner.de writes:

 Hi Cafe,

 this is an idea that has been floating in my head for a while, and I’m
 wondering about its feasibility and, if feasible, complexity (in the
 range from „trivial“ over “blog post” over “paper” to “thesis”).

 Application authors in Haskell often face the problem of run-time
 constants, e.g. values that are expected to be determined once during
 program start and then stay fixed for the remainder of the run. Good
 examples are user configuration values (--verbose, certain paths,
 debugging level, etc.).

There are two aspects to this, both of which have potential
solutions that I’ve been thinking about on and off for a long
time.

The first is command line arguments.

As far as I’m concerned they ought to be passed as a parameter
to the whole programme. So instead of main being a value
exported to the outside world and all importing of values being
done through the IO monad, we would have main going out and
argv::[String] as a global variable (which, of course would not
change during any run of the programme). The alternative version
of this, to make main::[String] - IO ExitCode has a superficial
cleanliness but doesn’t help with the general problem of having
to pass these things about, and in fact makes no real difference
to the referential transparancy of a programme.

The second is configuration data in files.

This seems to fall into two parts: the data that can be fixed at
link time and the data that changes from run to run. For the
former, a simple solution would be to have a facility to compile
a module from non-haskell data. This can be done with template
Haskell doing IO. So that leaves configuration data that changes
from run to run.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2010-09-14)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.IArray rant

[Jon Fairbairn]

Roman Leshchinskiy r...@cse.unsw.edu.au writes:

 On 03/09/2011, at 03:04, Ivan Lazar Miljenovic wrote:

 On 3 September 2011 11:38, Evan Laforge qdun...@gmail.com wrote:
  The result is that my first contact with haskell
 arrays left me with the impression that they were complicated, hard to
 use, and designed for someone with different priorities than me.  Of
 course, Data.Vector didn't exist back then, but if someone were new to
 haskell now I would recommend they skip Data.IArray and head straight
 for vector.
 
 To an extent, I wonder how much of this has been that arrays were
 considered to be bad in Haskell, so no-one used them and no-one
 bothered to try and improve the API much (and instead went and created
 Vector, etc.).

No, arrays were not considered to be bad, they were designed
with parallelism in mind. It’s just that no-one has really put
much effort into the implementation (partly because during the
first few years no-one wrote anything that used arrays much, and
then there’s a feedback loop no usage=no implementation
effor=no usage. Also there seem to be some misunderstandings.

 It's rather that some considered the IArray API to be
 inadequate most of the time. Really, H98 arrays aren't very
 good at anything they do. For collective operations, you are
 supposed to convert the array to a list, work on the list and
 then convert it back to an array which just seems wrong.

I am unconvinded that this is any more wrong than using a for
loop in an imperative language. Remember that the lists are
lazy, so it’s misleading to say “convert the array to a list”
since what happens most of the time is that elements are taken
out of the array and passed to the processing function and then
thrown away before the next element is processed.

 Multidimensional arrays can't be sliced and diced in the style
 of Repa or NumPy.

I’m not familiar with Repa or NumPy, but what can they do that
cannot be done with judicious use of ixmap, which is a very
powerful mechanism.

 In general, H98 arrays seem to have been designed with the
 goal of providing a container with O(1) indexing. They do
 that, I suppose, although they aren't very well integrated
 with the rest of the language

Can you give examples?

 and they have conceptual problems (such as requiring two
 bounds checks for one array access).

Assuming that you mean that for safe array access where nothing
is known about the index at compile time, since any sort of
array has at least a beginning and an end, they all require two
bounds checks. Once you do know something about the index, it’s
a question of implementation.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] xmonad on xkcd

[Jon Fairbairn]

http://xkcd.com/934/ (and look at the “hover text”) — so who’s
going to implement it?

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The Typeable class is changing

[Jon Fairbairn]

Carl Howells chowe...@janrain.com writes:

 This will affect snap-core and heist, of the things I've provided
 Typeable instances for.

 In snap-core, deriving makes it use the internal module name, rather
 than the canonical location of the type.  This causes issues with the
 Hint library, so it's worked around by using a manual instance of
 Typeable.

There’ll be a replacement for mkTycon (mkTycon3), so you can
still do manual instances…

 So, this change will hit me for two different reasons, and sadly
 involve using CPP to control how things are compiled.

so that shouldn’t be necessary.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comment Syntax

[Jon Fairbairn]

Albert Y. C. Lai tre...@vex.net writes:

 On 11-06-04 02:20 AM, Roman Cheplyaka wrote:
 It is, for my taste, a good comment marker, because of its resemblance
 to a dash. It makes the code look like real text:

let y = x + 1 -- increment x

 COBOL is real text, if that is what you want.

MOVE PROGRAMMER TO SARCASM
-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comment Syntax

[Jon Fairbairn]

Roman Cheplyaka r...@ro-che.info writes:

 * Andrew Coppin andrewcop...@btinternet.com [2011-06-03 18:12:04+0100]
 On 03/06/2011 05:02 PM, Albert Y. C. Lai wrote:
 I propose that only {- -} is comment; that is, -- is an operator token
 and not a marker of comments.
 
 I'm curious to know why anybody thought that -- was a good comment
 marker in the first place. (I'm curious because Haskell isn't the
 only language to have made this strange choice.)

 It is, for my taste, a good comment marker, because of its resemblance
 to a dash. It makes the code look like real text:

   let y = x + 1 -- increment x

And when the language was first defined, there was no real dash
available for this purpose. Nowadays we could use the unicode em
dash (U+2014, — if it survices nntp), and free up -- for other
purposes.

Of course, its hard to predict what effect this would have when
people didn't know how to enter it, and although it's quite
distinctive in proportional fonts, the difference between - and
— in monospace fonts is much harder to see.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2010-09-14)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: a simple question about types

[Jon Fairbairn]

Daniel Fischer daniel.is.fisc...@web.de writes:

 On Wednesday 17 November 2010 19:09:16, Jerzy M wrote:
 Hallo,
 let me take this simple function: (2*).
 If I check its type

 :t (2*)

 I'll obtain
 (2*) :: (Num a) = a - a

 But now it suffices to write
 g = (2*)
 and check

 :t g

 to obtain
 g :: Integer - Integer

 One more combination, now I write
 h x = (2*) x
 and check once more

 :t h

 to get
 h :: (Num a) = a - a

 So my question is: why (in this second example) Integer is inferred?
 What makes a difference?

 The monomorphism restriction.

And default. If you load this into ghci

   module Main where

   default (Int)

   g = (2*)
   main = putStrLn foo

and type :t g

you'll get Int - Int

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Catching up on Time and Directory

[Jon Fairbairn]

I'm probably terribly out of date with this, so I wonder if
anyone can save me the bother of working out what the
/preferred/ libraries are for (a) determining the
last-modified-time of a file or directory and (b) manipulating
the resulting time datum.

I can find System.Directory.getModificationTime and
Data.Time.formatTime, but using them together seems unduly
awkward.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2010-09-14)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Mysterious fact

[Jon Fairbairn]

Lennart Augustsson lenn...@augustsson.net writes:

 Jon, you beat me to it.  I was going to mention Ponder.

Strange chance; yesterday was the first time I read haskell café
for something like half a year.

 But Ponder did have a builtin type, it had the function type built in. :)

Well, to use the nomenclature of Ponder itself, (-) is a type
/generator/, not a type. So either it had no built-in types, or
it had infinitely many ;-)

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Mysterious fact

[Jon Fairbairn]

Andrew Coppin andrewcop...@btinternet.com writes:

 The other day, I accidentally came up with this:

 |{-# LANGUAGE RankNTypes #-}

 type  Either  x y=  forall r.  (x -  r) -  (y -  r) -  r

 left :: x -  Either  x y
 left x f g=  f x

 right :: y -  Either  x y
 right y f g=  g y

 |

 This is one example; it seems that just about any algebraic
 type can be encoded this way. I presume that somebody else
 has thought of this before. Does it have a name?

You could try reading my PhD thesis!
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-75.html
contains a link to the full text scanned to a pdf. (That -- 1985
-- was a long time ago. One thing I really regret about it is
that there should have been a comma between simple and typed
in the title. I suspect people think simply typed when they
see it). It isn't hard to read (one of my examiners said it made
good bed-time reading).

Anyway, the relevant part is that Ponder was a programming
language (Stuart Wray even wrote a GUI programme in it) that had
(in principle) no built-in types, relying on the type system
being powerful enough to express anything and the optimiser
being good enough to convert them to something more sensible.
In practice neither was /quite/ true, but it got quite close.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2010-09-14)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Function to find a substring

[Jon Fairbairn]

R J rj248...@hotmail.com writes:

 What's an elegant definition of a Haskell function that takes
 two strings and returns Nothing in case the first string
 isn't a substring of the first, or Just i, where i is the
 index number of the position within the first string where the
 second string begins?

f n h = listToMaybe [b | (a,b)- tails h `zip` [1..], n `isPrefixOf` a]

seems plausible, but how do you define elegant?

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Proof question -- (==) over Bool

[Jon Fairbairn]

Alexander Solla a...@2piix.com writes:

 On May 23, 2010, at 1:35 AM, Jon Fairbairn wrote:

 It seems to me relevant here, because one of the uses to which
 one might put the symmetry rule is to replace an expression “e1
 == e2” with “e2 == e1”, which can turn a programme that
 terminates into a programme that does not.

 I don't see how that can be (but if you have a counter
 example, please show us). 

Oops! I was thinking of the symmetry rule in general. What I
said applies to “a  b” and not to “a == b”, but my point was
that surely you can’t be sure of that until after you’ve
finished a proof that does consider ⊥?

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Proof question -- (==) over Bool

[Jon Fairbairn]

Alexander Solla a...@2piix.com writes:

 On May 22, 2010, at 1:32 AM, Jon Fairbairn wrote:

 Since Bool is a type, and all Haskell types include ⊥, you need
 to add conditions in your proofs to exclude it.

 Not really.  Bottom isn't a value, so much as an expression
 for computations that don't refer to real values.  It's
 close enough to  be treated as a value in many contexts, but
 this isn't one of them.

It seems to me relevant here, because one of the uses to which
one might put the symmetry rule is to replace an expression “e1
== e2” with “e2 == e1”, which can turn a programme that
terminates into a programme that does not.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Proof question -- (==) over Bool

[Jon Fairbairn]

R J rj248...@hotmail.com writes:

 I'm trying to prove that (==) is reflexive, symmetric, and
 transitive over the Bools, given this definition:

 (==):: Bool - Bool - Bool
 x == y =  (x  y) || (not x  not y)

Since Bool is a type, and all Haskell types include ⊥, you need
to add conditions in your proofs to exclude it.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Announcement: Data.ISO3166_CountryCodes version 0.1

[Jon Fairbairn]

John Millikin jmilli...@gmail.com writes:

 Thanks for the library! I'm sure it will be very useful for people
 dealing with internationalized applications / libraries. I have a few
 suggestions, which might make your library easier to use and maintain.

 First, it's very common to include generated files in the
 tarball.

Ah. That would solve the problem of the spurious empty .hsc file.

 This allows users to install the package, without installing 3rd-party
 utilities, or downloading (possibly varying) versions from external
 websites. As your library is currently written, two users who install
 it might end up with dramatically different modules, depending on the
 contents of  http://www.iso.org/iso/iso3166_en_code_lists.txt .

It would take a major global political ructions to make them
/dramatically/ different, but I'm aware of the issue...

 Second, since the module is based on an external data set, a
 date-based version might more appropriate. Version 0.1 means
 nothing, but version 2010.4.24 indicates when the given version was
 generated. Alternatively, you can use a hybrid system to indicate both
 stability and the date -- such as 0.1.20100424.

Something like this is already on my TODO list, but the date
that I want to appear in the version number would be the
last-modified-date of the downloaded code-list. How do I get
that (which the build already puts into a file¹) into the .cabal
file?

 Third, if you'd like your module to be widely used in the Haskell
 community, the BSD3 or MIT license would be more appropriate. For
 technical reasons, the GPL and LGPL are essentially equivalent for
 Haskell packages. For political reasons, choosing the GPL will reduce
 your user market to free-software users. This isn't *necessarily* bad
 -- all of my large projects are GPL'd -- but be aware that your choice
 will heavily limit how many people use your library.

Something close GPL is what I want -- if I'm doing this for
openly and for nothing, I don't see why anyone should build
something on the back of it and make it proprietary without me
having a say. I'd be happy to put a notice somewhere to the
effect that I'm willing to negotiate terms for a separate
license for inclusion in proprietary code, though I'd like to
know the proper way of doing that.

 Fourth, consider storing your code in a version control system (like
 Darcs[1]),

it already is.  

 and publishing it on a website like Patch-Tag[2].

I was waiting for it to be uploaded overnight. If my rsync
system isn't configured to delete it next time, 

   darcs get --lazy http://www.cl.cam.ac.uk/~jf15/ISO3166_CountryCodes/

should get a copy.

[
 trying that without the --lazy just now netted me this:
darcs: bug in darcs!
Another possible bug in URL.waitNextUrl:  curl_multi_perform() - no running 
handles at src/URL.hs:243 compiled Sep 12 2009 12:18:27
I'm unable to check http://darcs.net/maintenance to see if this version is 
supported.
If it is supported, please report this to b...@darcs.net
If possible include the output of 'darcs --exact-version'.

 which isn't encouraging.
]

 This enables people to contribute patches more easily. I've
 already checked it in as a branch[3]

That was a bit premature!

 -- either branch mine, or create your own trunk.

No! :-P

 Finally, instead of using a Makefile to build the library or
 documentation, consider using the cabal-install utility[4]. It's much
 more common for a library to use cabal build or cabal haddock than
 custom make commands, and external tools (such as Hackage) will work
 better.

I'd be grateful for a patch (against my repo) that did that.
I've used make for thirty years, so learning something else
doesn't hold great appeal.


[1] I was going to do something more sophisticated with the
last-modified-date, but in ghc 6.10.4 date and time handling
seems to be a bit of a mess, so I abandoned it.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: The instability of Haskell libraries

[Jon Fairbairn]

John Goerzen jgoer...@complete.org writes:

 It is somewhat of a surprise to me that I'm making this
 post, given that there was a day when I thought Haskell was
 moving too slow ;-)

 My problem here is that it has become rather difficult to
 write software in Haskell that will still work with newer
 compiler and library versions in future years.

I have the same problem, except that I work so slowly that
things have changed before I finish anything!

 Here is a prime example.  (Name hidden because my point here
 isn't to single out one person.)  This is a patch to
 old-locale:

 Wed Sep 24 14:37:55 CDT 2008  xx...@x.
   * Adding 'T' to conform better to standard
   This is based on information found at

 http://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations
 diff -rN -u old-old-locale/System/Locale.hs new-old-locale/System/Locale.hs
 --- old-old-locale/System/Locale.hs   2010-04-23 13:21:31.381619614 -0500
 +++ new-old-locale/System/Locale.hs   2010-04-23 13:21:31.381619614 -0500
 @@ -79,7 +79,7 @@
  iso8601DateFormat mTimeFmt =
  %Y-%m-%d ++ case mTimeFmt of
   Nothing  - 
 - Just fmt - ' ' : fmt
 + Just fmt - 'T' : fmt

 A one-character change.  Harmless?  No.  It entirely changes
 what the function does.  Virtually any existing user of that
 function will be entirely broken.  Of particular note, it
 caused significant breakage in the date/time handling
 functions in HDBC.

 Now, one might argue that the function was incorrectly
 specified to begin with.

It certainly was, and I said so in
wfmytn48x5@calligramme.charmers posted to the Libraries
list back in 2007:

 According to http://www.w3.org/TR/NOTE-datetime (and other
 random sources), the iso format for date+time in one field
 is -MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00), ie
 no spaces around the T but iso8601DateFormat outputs a
 space after the day if the timeFmt is not Nothing, so
 
 formatTime System.Locale.defaultTimeLocale
(System.Locale.iso8601DateFormat (Just T%H:%M:%SZ)) 
(UTCTime (fromGregorian 2007 10 20) 26540)
 
 yeilds 2007-10-20 T07:22:20Z.  I reckon this is a bug,
 but at the very least it's not a good design.  Please can we
 change
 
 
  Just fmt - ' ' : fmt
 
 to 
 
  Just fmt - fmt
 
 ?  if someone wants a space, they can put it in the string,
 but it's a pain to take it out when you want the one field
 format with a T there.

Now, while that change would still have been incompatible, I
think it would have hurt less. But the problem here is that no
one noticed my message, and then someone else must have seen the
problem and made the different change without checking through
old messages. If I remember correctly, I didn't report it as a
bug because (a) I had some problem accessing trac at the time
and anyway 2007-10-20 07:22:20Z is acceptable as a two field
format, so it was a feature request (make it possible to output
the correct single field format).  But no discussion ensued.

My own, related, gripe about Haskell libraries is that they seem
very patchy; not adhering very well to relevant standards and
not using Haskell's types enough. For your cited example, there
is an applicable standard, so it should have been written to
adhere to it and properly typed formats are rather awkward to
do, so that can be forgiven.  But in many other places Strings
are used, with the effect that there's no typechecking at all.

An example I came across yesterday: I wanted to read a file
modification time and use that as the If-Modified-Since header
in an HTTP request. System.getModificationTime returns one type
of date, and I couldn't find how to format that correctly
(There's old-time and new time -- which one do I choose for
future compatibility? And how /do/ I convert that date to
something I can format for http?), but more to the point, I
shouldn't have to care: the IF-Modified-Since header in HTTP
expects a date, and I got a date from the system, so it should
be typed that way; converting it to the right format for HTTP is
simple-HTTP's job.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: persist and retrieve of IO type?

[Jon Fairbairn]

Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes:

 Daryoush Mehrtash dmehrt...@gmail.com writes:

 Is there a way to persist a [IO ()] to say a file then retrieve it later and
 execute it using a sequence function?

 I'm not sure I understand what you're wanting... you can pass around
 values of type IO () around, but they won't be executed until you
 actually use them...

It sounds more like he wants two functions something like

save:: FilePath - [IO ()] - IO ()
restore:: FilePath - IO [IO ()]

to which the answer would be no.
-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Integers v ints

[Jon Fairbairn]

Jens Blanck jens.bla...@gmail.com writes:

 On 1 April 2010 10:53, Ivan Lazar Miljenovic ivan.miljeno...@gmail.comwrote:
 Jens Blanck jens.bla...@gmail.com writes:
  I was wondering if someone could give me some references to
  when and why the choice was made to default integral
  numerical literals to Integer rather than to Int in
  Haskell.

Seems to have been in 1998.  I don't have a complete archive of
the discussion, though, and I don't know where to find the
Haskell 98 committee minutes on-line.

 My guess is precision: some numeric calculations (even doing
 a round on some Double values) will be too large for Int
 values (at least on 32bit). Note that unlike Python, etc.
 Haskell doesn't allow functions like round to choose between
 Int and Integer (which is equivalent to the long type in
 Python, etc.).

 Ints have perfect precision as long as you remember that it
 implements modulo arithmetic for some power of 2. I was hoping
 that the reason would be that Integers give more users what
 they expect, namely integers, instead of something where you
 can add two positive numbers and wind up with a negative
 number.

As I interpret the part of the discussion I have on file, there
are two reasons: 

(1) as you hoped, because Integers are what people expect:
reasoning on Integers is more reliable -- you can't do induction
on Int, for example, and people don't generally try to prove
that they've implemented

 f x = the_f_they_originally_wanted x `mod` 2^32

(2) good language design. One of the things I've repeated over
the years is that Int doesn't have to be part of the language
(it's just another peculiar type that should be defined in a
library) but Integer does, because without it there's no way to
specify the meaning of an Integral constant¹.

  Jón


[1] This isn't quite true; using subtyping one could make
Integral constants into [Digit] and leave the conversion to the
point where overloading is resolved, but that's a much longer
story.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Are there any female Haskellers?

[Jon Fairbairn]

Leon Smith leon.p.sm...@gmail.com writes:

 On Sat, Mar 27, 2010 at 1:56 PM, Jason Dagit da...@codersbase.com wrote:
 For some reason it started out as a male dominated field.
 Let's assume for cultural reasons.  Once it became a male
dominated field, us males  unknowingly made the work and
learning environments somewhat hostile or unattractive to
women.  I bet I would feel out of place if I were the only
male in a class of 100 women.

 Is this really true?  I've heard rumors that in the early days of
 programming, that women were in the majority,  or at least they
 represented a much greater proportion of programmers than they do now.
   I seem to recall that this started to change sometime in the 60s.

One thing I observed of the Computer Science Tripos in Cambridge
was that the absolute number of women doing the course didn't
change much, but the size of the course increased over the
years. This suggests that men went into it because it was
trendy, but for the most part women went into it because they
found it interesting (and the proportion of women in the general
population who find it interesting was roughly constant). This
was twenty years ago, and I don't know if the subsequent data
supports the hypothesis.

Another (provocative) observation is that most of the women
programmers I've known were good at it and thought they might
not be, but most of the men claimed to be good at it but
were not.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: showing Ratios

[Jon Fairbairn]

Evan Laforge qdun...@gmail.com
writes:

 On Mon, Mar 1, 2010 at 1:29 AM, Jon Fairbairn
 jon.fairba...@cl.cam.ac.uk wrote:
 Iavor Diatchki
 iavor.diatc...@gmail.com writes:

 Hi,
 I am not sure about the rationale but if you need a program/library
 which re-renders Show-able values with more spaces, so that they are
 more human readable,  I wrote one
 (http://hackage.haskell.org/package/pretty-show).  I find it very
 useful for debugging.

 This comes up sufficiently often that perhaps the Show class
 should have readableShow that defaults to the same as show.

 The thing I was curious about was why Show doesn't default to a more
 pretty output in the first place.

Probably because that's not what it was originally intended for.

 I actually have a separate Pretty class

So do quite a few people!

 which, unlike Show, is under
 no obligation to produce parseable or even unambiguous output.  This
 is similar to Python's concept of separate str() and repr() functions.

It makes little difference to me whether we have different
classes for Pretty and Show or just a pshow in Show

 And then a separate 'pshow :: Show a = a - String' produces 'show'
 output but with newlines and all lined up.  The missing bit is a
 Pretty that produces a Text.PrettyPrint Doc, but this can all be done
 without recourse to modifying the Prelude.

I think my argument is that producing human-readable output is a
sufficiently common requirement that it should be fairly
available from somewhere everyone knows to look. Personally, I'd
remove most of the prelude and put more of it in standard
libraries that everyone is expected to know about early on in
learning the language.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: showing Ratios

[Jon Fairbairn]

Iavor Diatchki
iavor.diatc...@gmail.com writes:

 Hi,
 I am not sure about the rationale but if you need a program/library
 which re-renders Show-able values with more spaces, so that they are
 more human readable,  I wrote one
 (http://hackage.haskell.org/package/pretty-show).  I find it very
 useful for debugging.

This comes up sufficiently often that perhaps the Show class
should have readableShow that defaults to the same as show.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011

[Jon Fairbairn]

Anthony Clayden
anthony_clay...@clear.net.nz
writes:
 (I know how you're always looking for things to take out of
 Haskell ...)

 I can see the ugliness of having a name with two
 incompatible types (especially in the same scope).

Granted.

 After all, the program text declares { f :: Int }, and in
 all uses of the field label apart from selecting, it _is_ an Int.

It's not; it's shorthand for something else (a bare f in a
programme doesn't get you an Int -- which one would it be?). One
of the nice things about Haskell is that if you know the name of
something and the something has a type, then you know something
about all the possible values it can have. In current Haskell, f
here isn't a name in that sense, which is a big pity (you can't
pass a field label as an argument to a function, for example).

 Where does this function thing come from?

It comes (as you imply) from it's use as a field selector. I'd
say that (and field update) were its primary uses. It would be
far better to make field labels proper first-class entities that
have a translation into lambda calculus (or System F as you
will).

I would much rather see field labels having their own type,
so that

  data F t = F {f:: H t}

declares the type F, the constructor F and a name 

f:: Selector (F t) (H t)

the language definition needn't make whatever is inside Selector
directly visible to the programmer, but we can think of it as
secretly being a pair of functions

 ((F t - H t), (H t - F t - F t))

Now f x would be an overloaded meaning of application¹. And
r{f=g} would be shorthand for (magic-snd f g r), where magic-snd
is just snd made suitable for application to Selector. (Frankly,
I'd rather lose the r{f=g} syntax and provide an operator that
accesses the second part of f so that it can be applied as a
function, eg (f←g) r. This (f←g) would then also be a first
class function.)


Doing it this way would get rid of the peculiar multiple type
issue, make it completely clear what field labels translate to
and give us field labels as proper first class entities.


[1] as it currently is, and I'm not suggesting allowing general
overloading of application, but at least this way we'd know what
f was

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Negation

[Jon Fairbairn]

Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com
writes:

 Lennart Augustsson wrote:
 Of course unary minus should bind tighter than any infix operator.
 I remember suggesting this when the language was designed, but the
 Haskell committee was very set against it (mostly Joe Fasel I think). 

 Are there archives of this discussion anywhere?

If it was on the fplangc mailing list, the archive exists
somewhere (Thomas Johnsson had it in the past). If it was at one
of the committee meetings, Thomas or Lennart had a tape recorder
running. I remember asking some time later what happened to this
and got a reply that contained the phrase teknisk missöde,
which doesn't take much of a grasp of Swedish to guess the
meaning of.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

[Haskell-cafe] Re: Allowing hyphens in identifiers

[Jon Fairbairn]

Daniel Fischer daniel.is.fisc...@web.de writes:

 Am Dienstag 15 Dezember 2009 03:04:43 schrieb Richard O'Keefe:
 On Dec 14, 2009, at 5:11 PM, Daniel Fischer wrote:
  1. I wasn't playing in the under_score vs. camelCase game, just
  proposing a possible
  reason why the camelCase may have been chosen for Haskell's standard
  libraries.

 But the insanely abbreviated example did not provide such a reason.

 Of course not. But if you expand it - and it's not difficult,
 even when insanely abbreviated -, the resulting sentence gives
 a possible reason: Maybe it's because the underscore style is
 considered far uglier and less readable by others. If the
 early Haskellers felt that way, isn't it perfectly natural
 that they chose the camelCase style?

As one of the early Haskellers, I definitely preferred
underscores, because my intuition told me that it was closer in
appearance to normal English¹ text, and my belief was that even
programmers read more English than code. Unfortunately I'm not a
very persuasive person, and couldn't argue my case (beyond
having underscores /permitted/). The problem is that once people
have spent some time using one style or other, their ability to
self-analyse their reading of it becomes negligible. Ugly and
less readable become synonymous with not the style I'm used
to, irrespective of actual effects on reading speed. And
introspection is a notoriously bad method of anyalysing
psychological factors in the first place.

This really should have been decided with proper experiments.

 Of course, they may have had entirely different reasons, or no
 concrete reason at all and it just happened.

In the absence of hard data, it only takes a slight bias in
exposure among members of the committee to tip a decision the
wrong way.

[1] and quite a high proportion of other natural languages.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Allowing hyphens in identifiers

[Jon Fairbairn]

Deniz Dogan deniz.a.m.do...@gmail.com writes:

 2009/12/8 Jon Fairbairn jon.fairba...@cl.cam.ac.uk:
 Deniz Dogan deniz.a.m.do...@gmail.com writes:

 [...] allow hyphens in identifiers, much like in Lisp
 languages? E.g. hello-world would be a valid function name.

 I (among others) suggested it right at the beginning when we
 were first defining the lexical syntax

 I just like the standard Lisp naming convention better than camel
 casing and saw someone on #haskell mentioning it the other day. No
 biggie though.

I prefer it too, but as far as Haskell is concerned, it's one of
those things that's not really worth changing at this stage of
its life. Changing the syntactic category of Unicode HYPHEN
(U+2010) might still be possible, but someone (with more stamina
than me) would have to advocate it.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Allowing hyphens in identifiers

[Jon Fairbairn]

Deniz Dogan deniz.a.m.do...@gmail.com writes:

 Has there been any serious suggestion or attempt to change the syntax
 of Haskell to allow hyphens in identifiers, much like in Lisp
 languages? E.g. hello-world would be a valid function name.

I (among others) suggested it right at the beginning when we
were first defining the lexical syntax, and have raised the
possibility again a couple of times now that unicode hyphens are
available, but it wasn't liked at the beginning and hasn't
excited much interest since.  Why do you want them?

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Fwd: Is () a 0-length tuple?

[Jon Fairbairn]

Pasqualino \Titto\ Assini tittoass...@gmail.com writes:

 The syntax is similar, but what else is?

What would you expect from an empty tuple?

(a,b,c) has a constructor function p3 a b c = (a,b,c) and three
destructor functions s3_1 (a,b,c) = a, s3_2 (a,b,c) = b and s3_3 (a,b,c)=c

(a,b) has a constructor function p2 a b = (a,b) and two destructor functions
s2_1 (a,b) = a and s2_2 (a,b) = b

(a) has a constructor function p1 a = (a) and one destructor function 
s1_1 a = a

() has a constructor function p0 = () and zero destructor functions.



 In JavaScript there is a null value, that is the only value of the
 null type.

I'm not sure that Javascript is a suitable place to get intuitions for
Haskell (null type would seem more like empty than single), but anyway,
the thing is that the sole (non-bottom) value of the /unit/ type is the
same as the empty tuple¹.

 Isn't () the same thing?  The only value of the unary type?

The empty type in Haskell would be (forall a.a) which has no
non-bottom values.


[1] Aside: I wanted haskell to share the same type for all empty values
(ie lists would have been symmetric unions of pairs with the unit type
List t = (t,List t) || ()), but that didn't fit with algebraic datatypes
so the design went a different way.
-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Curried function terminology

[Jon Fairbairn]

David Virebayre dav.vire+hask...@gmail.com writes:

 On Mon, Oct 5, 2009 at 11:52 AM, Jon Fairbairn
 jon.fairba...@cl.cam.ac.uk wrote:

 [1] A pet peeve of mine is x supports y being used backwards (as in
 our application supports windows Vista, which would only make sense if
 it were something like a system tool that stopped Vista crashing.

 (Not a native English speaker here)

 How would you say  x works well with y ?

I think I would say x works well with y. There's no reason to abuse
support (which carries an implication of one thing being on top of
another) for this.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Curried function terminology

[Jon Fairbairn]

michael rice nowg...@yahoo.com writes:

 This is from Learn You A Haskell:

 ==

 Curried functions

 Every function in Haskell officially only takes one
 parameter. So how is it possible that we defined and used
 several functions that take more than one parameter so far?
 Well, it's a clever trick! All the functions that accepted
 several parameters so far have been curried functions. What
 does that mean? You'll understand it best on an example.
 Let's take our good friend, the max function. It looks like
 it takes two parameters and returns the one that's bigger.
 Doing max 4 5 first creates a function that takes a
 parameter and returns either 4 or that parameter, depending
 on which is bigger. Then, 5 IS APPLIED TO THAT FUNCTION and
 that function produces our desired result.

 What really happens when we do multThree 3 5 9 or
 ((multThree 3) 5) 9? First, 3 is applied to multThree,
 because they're separated by a space. That creates a
 function that takes one parameter and returns a function. So
 then 5 IS APPLIED TO THAT, which creates a function that
 will take a parameter and multiply it by 15. 9 IS APPLIED TO
 THAT FUNCTION and the result is 135 or something.

 ===

 The language (in CAPS) in the above two paragraphs seems to
 be backwards.

It is. 5 is applied to that function should be 5 is supplied to that
function (or that function is applied to 5) and so on. It's a fairly
common error in writing this sort of thing¹, and given that the title
Learn You A Haskell is totally ungrammatical, hardly seems surprising.

 In the first paragraph, since functions are
 conventionally applied to parameters shouldn't it read
 something like THE PARTIALLY APPLIED FUNCTION IS THEN
 APPLIED TO the 5? Or is the terminology different for
 Haskell, 

No, but Haskell does have a lot of non-native users of English among its
users.


[1] A pet peeve of mine is x supports y being used backwards (as in
our application supports windows Vista, which would only make sense if
it were something like a system tool that stopped Vista crashing.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Cabal packages - cabbages

[Jon Fairbairn]

Conor McBride co...@strictlypositive.org writes:

 On 20 Sep 2009, at 23:11, Jason Dusek wrote:

  Some day, we're going to need a short, catchy name for Cabal
  packages. Let's call them cabbages.

 Not that this is a good reason to change your mind, but some
 sufficiently ancient Brits may remember a televisual

Speaking of ancient Brits, the Finns used to call Britain
cabbage-land, in case that alters anyone's opinion.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell-beginners] map question

[Jon Fairbairn]

Ketil Malde ke...@malde.org writes:

 Gregory Propf gregorypr...@yahoo.com writes:

 Heh, perhaps we should petition to have a new computer key and symbol
 added to the world's way of writing maths, something like maybe a
 downward angled slash to mean prefix (-)  

 Or just use 'negate' and 'subtract'?

Well, now that ghc accepts unicode characters in programme source, we
could ask that ¬ (NOT SIGN, U+00AC) be recategorised as an identifier
character and use that (as a simple function name) for negation and lose
the wart altogether.

class Negatable t where
  ¬ :: t - t

(and as a side effect we could have identifiers like slightly¬dodgy).

Or, if we want to make things look even nicer, make ‐ (HYPHEN, U+2010)
an identifier character and use − (MINUS SIGN, U+2212) for the infix
operator. Now we could have hyphenated‐identifiers too.

I think this second option would be the ㊣ (CORRECT, U+32A3) thing to
do, though editors and so on would have to be changed to make the
distinction readily visible.

I think it's Friday, but I'm not entirely sure this is silly.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Mapping over multiple values of a list at once?

[Jon Fairbairn]

Raynor Vliegendhart shinnon...@gmail.com writes:

 Just wondering, what should be the expected output be of something
 like mavg 4 [1..3]? [3%2] or []?

[0%1, 1%4, 3%4, 3%2, 3%2, 5%4, 3%4, 0%1], of course ;-P


-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANN: Typeful/Text/HTMLs (for AngloHaskell/for scrap?)

[Jon Fairbairn]

Colin Paul Adams co...@colina.demon.co.uk writes:

 Jon == Jon Fairbairn jon.fairba...@cl.cam.ac.uk writes:
 Jon darcs get --partial
 Jon http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs

 Did you make any progress on this at Anglo-Haskell?

Not really, owing to Microsoft site security ;-) [not that they were
being unreasonable, just that it cut me off rather abruptly]. I've
started some notes connected with this at
http://www.cl.cam.ac.uk/~jf15/Haskell-notes/AngloHaskell2009-Not-Talk.xhtml
(which as implied is not quite finished), though they are not especially
interesting to anyone who simply wants to use the library.

 Will it be cabal-ized soon?

That depends on whether anyone wants it done sufficiently strongly to do
it... at the moment I'm not motivated to learning how to do it (if I get
past all the non-programming stuff on my life to-do list, there are
several things on the project's TODO list that come before Caballise).
After all, if I'm the only person using the library, there's no reason
to caballise... granted, that smacks of a self fulfilling prophecy, but
I'm led to believe that if someone already knows cabal, it would be the
work of moments to do the job, whereas learning it would take
significant effort¹

The license would need attention too... in the absence of convincing
arguments to the contrary, I would favour GPL myself.


[1] And by the time I next wanted to do it, the chances are it would
have changed so much (or I would have forgotten it anyway) that I'd have
to learn it again.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Proposal: FirstClassFieldUpdates

[Jon Fairbairn]

Simon Peyton-Jones simo...@microsoft.com
writes:

 | Proposal: FirstClassFieldUpdates
 | 
 | Summary: Add some syntax that makes field updates into
 | functions.

 I'm wary about occupying too much syntactic space with
 Haskell's named-field notation. If you had a keyword, like
 update { foo = bar } meaning \x. x { foo = bar } that'd get
 you into a new syntactic space.

It'd also make the syntax too noisy to be of any interest.

 But braces alone are so precious that I'm not sure that record
 updates justify consuming them.

I'm not particularly wedded to braces, it's simply that they are
the syntax already used for updates, so to make updates first
class that is the obvious choice.

For first class updates I'd be happy with something like “foo :=
bar”, but then I would want the syntax of record construction to
be something similar.

For some reason, the use of braces in record syntax differs from
all others I can think of: all the rest are x {something;
something; something} and can replaced by layout. So braces
(with commas) for records at all is an irregularity.


 On a related matter, people want to use record syntax for
 GADTs and existentials. For record selection and
 construction these are more or less fine (ie one can make a
 sensible spec). But record update is another matter. Haskell
 98 says that record update can change the type of a record
 (contrary to some posts in this thread), but the
 specification becomes really rather tricky for GADTs and
 existentials. Indeed, I was going to propose that in H Prime
 we might consider making update *not* change the type,
 backing away from the current H98 story, but one that makes
 the spec a lot easier. But various people have been arguing
 in favour of the H98 story so I may have an uphill struggle!

I'm coming back to this stuff rather late; I can't say I
understand the interactions between GADTs, existentials and
records. In the absence of those developments what I would have
liked to have seen would have been a decomposition of data
declarations and the resulting types into orthogonal parts. For
one thing, allowing “Constr a b c” for construction and pattern
matching on something that was declared as “Constr {x::A, y::B,
z::C}” looks improper to me, and another is the restricted
nature of Haskell’s union types (cf what I started to talk about
at AngloHaskell; see
http://www.cl.cam.ac.uk/~jf15/Haskell-notes/AngloHaskell2009-Not-Talk.xhtml
for some notes on that)

So the outline would be (forgive the poor choice of keywords
here):

1. distinguishable types

The type “dtype Constr T1 T2…” would correspond to a single
alternative of a data declaration (dtype is just an arbitrary
keyword from distinguishable type). The idea is that two dtypes
only match if their (fully qualified) constructors match.

2. Symmentric unions of distinguishable types

A type (dtype1 | dtype2 | …) corresponds to the alternatives of
a data declaration. Note that “|” can only be used on
distinguishable types (and unions of distinguishable types). So
a non-record-syntax data declaration

data Widget = Thing1 A | Thing2 B | …

could still be valid but now be a shorthand for 

type Widget = dtype Thing1 A | dtype Thing2 B | …

One of the benefits of this is that the type of anything can be
written down without having to refer to any declarations.

3. Once that is done, we can come up with a design for records:

field1:=x . field2:=y . … $ emptyRecord

Now “field:=x”; is a first class function, polymorphic on all
records that have “field” as a field. We might want to choose
some nicer syntax for emptyRecord, (“{}” if you like), but the
only other expression syntax needed is the pseudo operator “:=”,
though some syntax for the types would need to be designed.
“record (field1::Type1, …)” would do, with “record ()” for the
empty record. There is no /need/ to use up precious braces ;-).

* * *

You’ll complain that this isn’t fully worked out, and as I say,
I don’t know how it interacts with GADTs and other things I’m
not up to date with. But as far as I remember, I could simulate
all of this in Ponder’s type system, so it shouldn’t be too hard
for someone au fait with the way things are currently done to
specify it properly.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

[Haskell-cafe] ANN: Typeful/Text/HTMLs (for AngloHaskell/for scrap?)

[Jon Fairbairn]

A while ago I wrote this rather pedantic html library (it guarantees
standards compliance via types, even down to the nesting restrictions).
I announced it on the libraries list, but chronic fatigue gets in the
way of following things up, so I haven't taken it any further until
recently. And recently there have been other efforts in the HTML area
that may make it out of date.

Anyway, I think there are one or two useful ideas in it, and if I manage
to get to AngloHaskell, I'd like to discuss it a bit, hence the
announcement (rather closer to AH than I intended).

You can get the whole thing with 

darcs get --partial 
http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/nHTMLs
It should build with ghc 6.10 and haddock 2.4.2

or you can browse the documentation starting at 
http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs/Documentation/haddock/Typeful-Text-HTMLs.html

and AngloHaskell people who are interested might want to look at
http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs/TODO


-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANN: Typeful/Text/HTMLs (for AngloHaskell/for scrap?)

[Jon Fairbairn]

I wrote:
 You can get the whole thing with 

 darcs get --partial 
 http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/nHTMLs

but that was a temporary url that I copied and pasted. The correct one:

darcs get --partial 
http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs

And I uploaded only a partial get because I don't have much space on
that server, but apparently darcs 2.3 can't get --partial from that
repo, so I've uploaded the whole thing for now.

Thanks to Max Desyatov for pointing out these problems.

And one of the tests failed because Bolivia is now the Plurinational
State of Bolivia, so I've add a patch for that. I've seen politics get
in the way of programming, but I've never had a bug caused by
/international/ politics before.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Need feedback on my Haskell code

[Jon Fairbairn]

CK Kashyap ck_kash...@yahoo.com writes:

 line' (x1, y1) (x2, y2) deltax deltay ystep isSteep error
   | x1 == x2 = if isSteep then [(y1, x1)] else [(x1, y1)]
   | isSteep =
 (y1, x1) :
   line' (newX, newY) (x2, y2) deltax deltay ystep isSteep newError
   | otherwise =
 (x1, y1) :
   line' (newX, newY) (x2, y2) deltax deltay ystep isSteep newError
   where newX = x1 + 1
 tempError = error + deltay
 (newY, newError)
   = if (2 * tempError) = deltax then
   (y1 + ystep, tempError - deltax) else (y1, tempError)

It's early in my day, so I'm not very awake, but this looks like it
could be an iterate or something like that, rather than explicit
recursion.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Adding a field to a data record

[Jon Fairbairn]

Henry Laxen nadine.and.he...@pobox.com writes:

 It seems to me this should be easy, but I can't quite figure out
 how to do it without a lot of typing.  Here is the question:

 Suppose you have a data type like:
 Data Foo = Foo { a :: Int, b :: Int, 
... many other fields ... 
  y :: Int } deriving (Eq, Read, Show, Typeable, Data)

 Now I would like to add a field z :: Int to the end of Foo.  If
 I have a ton of data out on disk, which I wrote with, say
 writeFile a.data (show foo) -- where foo is a [Foo] say 1000
 long, I would like to get a new a.data file which has a new
 z::Int field.

One approach to this would be to temporarily redefine Foo

data Foo = Foo { a :: Int, b :: Int, 
... many other fields ... 
y :: Int } deriving (Eq, Read, Show, Typeable, Data)
 | NuFu {a :: Int, b :: Int,
... many other fields ... 
y :: Int,
z :: Int} deriving (Eq, Read, Show, Typeable, Data)

read the file, map Foo to NuFoo + whatever the initial value of z is
and write it out again.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Proposal: FirstClassFieldUpdates

[Jon Fairbairn]

Isaac Dupree
m...@isaac.cedarswampstudios.org
writes:

 Jon Fairbairn wrote:
 Parenthesis around updates would make them into functions, ie
 ({a=1,b=2,...}) would mean the same as (\d - d{a=1,b=2,...}), but be
 more concise.

 yes it is, however field updates are occasionally slightly
 annoying, since they can't change something's type at all,
 IIRC.  Say,
 data C nx ny = C { x :: nx, y :: ny }
 x_set :: nx2 - C nx1 ny - C nx2 ny
 --x_set x2 c = c {x = x2}  --type error

If that were the case, it would be a serious wart that needed to be
addressed. However, implementation would be fairly straightforward as
an extension is already present in ghc:

   let x_set x2 c = c{x=x2}
   :t x_set
   x_set :: nx - C t ny - C nx ny

;-) (or did I misunderstand you?)

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: StricterLabelledFieldSyntax

[Jon Fairbairn]

Neil Mitchell ndmitch...@gmail.com
writes:

 Hi

 Would it be proper to create a counterproposal for this syntax?
 ReversedLabelledFieldSyntax?

 I would claim that, of the existing Haskell code,
 StricterLabelledFieldSyntax only rejects unclear (bad) code, and
 requiring it be changed (to be made clearer) is a good thing.

 I haven't seen anyone else claim to use the current more liberal
 syntax for fields, but I know that I do rather extensively. I would
 consider:

 Just A {a = 1}

 To be confusing, but if you simply omit the space:

 Just A{a = 1}

 I now find that perfectly clear and unambiguous. I realise this isn't
 necessarily a discussion of the merits of the feature, but I don't
 consider this removal as clear cut as some people are suggesting.

for what it's worth, I do take advantage of the current syntax for
functions with default parameters:

  f defaults{some_option = non_default_value}

and like you, I don't put a space. I've long thought that compilers
should issue warnings for layout that conflicts with precedence --
everyone knows that 2+2 * 8 means 2 + (2*8), but I'd guess it takes a
/tiny/ bit longer to read correctly, and for less familiar operators the
misleading layout is more likely a source of misreadings.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Proposal: FirstClassFieldUpdates

[Jon Fairbairn]

According to the wiki, since I'm not a committee member, I should post
proposals here. See below my reply to Isaac's message.

Isaac Dupree
m...@isaac.cedarswampstudios.org
writes:

 Jon Fairbairn wrote:
 Ian Lynagh ig...@earth.li writes:
 [field update] /has/ the
 binding level of function application. ie, instead of a{x=42} one would
 have to write {x=42}a,

 we already know which record type it is, because record
 fields don't have disambiguation.

OK, I'd forgotten that. Makes things straightforward.

 I think it wouldn't be a terrible syntax, ({...}), kind of
 like infix operators can be made into functions like (+).
 If you wanted to make a proposal for such an extension.

I was wondering how to make it compatible. That looks like a reasonable
compromise, so...

Proposal: FirstClassFieldUpdates

Summary:
Add some syntax that makes field updates into functions.

Description:

On several occasions I've wanted to pass arguments that modified records
and been disappointed that I have to use a lambda expression.

Parenthesis around updates would make them into functions, ie
({a=1,b=2,...}) would mean the same as (\d - d{a=1,b=2,...}), but be
more concise. This chimes reasonably well with (+) turning an infix
operator into a function. ({}) would be the (polymorphic) identity
function.

This would permit concise calls to functions with default/optional
parameters:

 data Defaults_for_f = Defaults_for_f {option1::A, option2::B, ...}
 defaults_for_f = Defaults_for_f {option1=default1, ...}

 f options other arguments = let params = options defaults_for_f in ...

allows one to write f ({}) ... (or f id ... if no-one likes ({})) to
call f with the default arguments, or f ({option1 = something_else}) ...
to go away from the defaults.

Discussion:

I would rather make {field1=a, field2=b, ...} a function. ie instead of
a{thing=1} one would write {thing=1} a. In other words {field1=a,
field2=b, ...} would be a notation for the function that is currently
written \d - d{field1=a, field2=b, ...}. Again we would want empty
record updates {} to be the identity function. We would then remove the
thing{fu=bar} syntax (where thing is a variable).

This would simultaneously simplify the syntax, remove the misleading f
x {a=b} bemoaned in StricterLabelledFieldSyntax and make certain use
cases (such as default parameters) more concise. Unfortunately old
programmes wouldn't compile any more¹, but I think that Haskell' is the
place for backwards incompatible changes that simplify things.

The difficulty would be what to do about Constructor{fu=bar}, given that
Constructor is currently defined to operate both as a function and be
used in patterns (there's something fishy about this when the record has
named fields). As yet I haven't thought of a good way of doing that,
hence the current proposal that adds syntax rather than takes it away.


[1] All the errors would be compile time errors.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: StricterLabelledFieldSyntax

[Jon Fairbairn]

Ian Lynagh ig...@earth.li writes:
 http://hackage.haskell.org/trac/haskell-prime/wiki/StricterLabelledFieldSyntax

I approve of the principle -- the binding level is confusing, but I
would far rather make a bigger change, so that rather than being
confusable with the binding level of function application, it /has/ the
binding level of function application. ie, instead of a{x=42} one would
have to write {x=42}a, and f {x=42} a would parse as (f {x=42}) a --
and be an error because labelled field assignments aren't currently
proper functions (but under this change they could be thought of as
a restricted kind of function).

This would allow a future change that made them first class citizen;
{x=42} would have type something like (Num a = forall D. D{x::a} -
D{x::a}) (if you can work out the intent of a syntax made up on the spur
of the moment). Working out the ramifications of a type system that
allowed that is a job for later, but it would be worthwhile to make it
possible.


Would it be proper to create a counterproposal for this syntax?
ReversedLabelledFieldSyntax?

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

[Haskell-cafe] Re: Implicit concatenation in list comprehensions

[Jon Fairbairn]

Bulat Ziganshin bulat.zigans...@gmail.com writes:

 Hello Neil,

 Tuesday, July 21, 2009, 1:26:55 PM, you wrote:

  ++ [ -i      | not (null (ghcOptSearchPath opts)) ]
  ++ [ -i, dir | dir - ghcOptSearchPath opts ]

 Following the discussions, I now support this extension too - I keep
 seeing more and more places in my code where it would be very useful.

  ++[ -i        | not (null (ghcOptSearchPath opts)) ]
  ++ concat [ [-i, dir] | dir - ghcOptSearchPath opts ]

That looks good enough to convince me that new syntax gains too little
here. When adding stuff to the syntax you have to be very careful about
interactions between forms, and possible errors. The more you add, the
more likely it is that something horrible gets overlooked. And learning
haskell becomes more tedious (you have to learn stuff that you'd never
use because other people will).

Having a fairly small amount of flexible syntax (and Haskell is already
pushing the boundaries of fairly small) together with powerful
abstraction tools is far better than having a syntax so huge that no-one
can see how weak the abstractions are... I keep trying, but I don't
think I can finish this posting without mentioning Perl, whose
aficionados have so much investment in having learned all that crap that
they can't see how awful it is.


-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: was: Debugging methods for haskell structured data types the right way in haskell

[Jon Fairbairn]

Fernan Bolando fernanbola...@mailc.net writes:

 On Sun, Jul 19, 2009 at 7:40 AM, wren ng thorntonw...@freegeek.org wrote:
 Fernan Bolando wrote:

 The intention is z0 is a system parameter and database, it contains a
 set of info needed to define a particular simulation

 A single-constructor ADT, especially with the labeled-fields syntax, is
 pretty close to C structs; no need to reinvent them and give yourself
 headaches.


 Really, the only thing you should be using lists for is a variable-length
 sequence of elements drawn from the same type and distinguished only by
 their position in the sequence.

 This is the kind of code recommendations I was looking.

I'd worked out a longer reply over the weekend, but wren got there first
(It hadn't occured to me that anyone would write that much code without
knowing about algebraic types, so thought something else was going on).

I'd like to add that thinking about the C code for a programme like this
is counterproductive. If you are doing various mathematical operations,
it's better to go straight from the mathematics to Haskell, and work out
the appropriate abstractions (in Haskell) for the operations you are
using. You'll generally end up with much shorter code that is easier to
maintain.

It might be worth pointing out that you can do things with Haskell data
structures that you can't do conveniently in C. For example, if you were
doing something that involved calculating the determinants of matrices
fairly often, but you didn't know in advance which matrices, you could
define your own matrix type like this (roughly):

data MyMatrix t = MM {theNumbers:: Matrix t, my_determinant:: t}

make_matrix m
= MM {theNumbers = m, 
  my_determinant = determinant m
 }

and then use make_matrix whenever you make a new matrix and
my_determinant whenever you want a determinant.

Now, although to a C programmer this looks like you calculate the
determinant of every matrix, laziness means that you only calculate the
ones you use, and calculate them at most once for each matrix.


-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Debugging methods for haskell

[Jon Fairbairn]

Henning Thielemann lemm...@henning-thielemann.de writes:

 On Thu, 16 Jul 2009, Fernan Bolando wrote:

 Hi all

 I recently used 2 hours of work looking for a bug that was causing

 Program error: Prelude.!!: index too large

 A good way to avoid such problems is to avoid partial
 functions at all. (!!) is also inefficient. Is it possible
 to define the function in terms of foldl?

I've looked at the code a bit more, and, with apologies to the original
poster, it doesn't look much like Haskell. For example, in
http://plan9.bell-labs.com/sources/contrib/fernan/escomma/Circuit.hs
there's stuff beginning with

   tADM :: Int
   tADM = 1

   tVSRC :: Int
   tVSRC = 2 

   tISRC :: Int
   tISRC = 3

   ...

that I think probably should be

   data Something = ADM | VSRC | ISRC ... deriving (Enum, ...)

though when I get to (((fst z0)!!pMSET)!!pMTYPE) == mOP I'm at a loss
to determine quite what the intention is. Maybe it should be an array
indexed by enum types, maybe a function, maybe something that can be
pattern matched on? I don't know.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Debugging methods for haskell

[Jon Fairbairn]

Fernan Bolando fernanbola...@mailc.net writes:

 Hi all

 I recently used 2 hours of work looking for a bug that was causing

 Program error: Prelude.!!: index too large

 This is not very informative. It did not give me a hint which function
 was causing this. In C adding a few printf would have helped me, but
 in haskell I was not sure how to do that. Can anybody point me to some
 debuggin method everyone uses.

 After 2 hours I did find the bug eventually. The code can be viewed here.
 Maybe some reformatting of the code would make finding bugs easier?
 http://plan9.bell-labs.com/sources/contrib/fernan/escomma/

I wonder if your code has to use !! at all? I took a look at a random
module from the above link, and (without making much attempt at
understanding it), I'd guess that using accumArray and friends would be
more appropriate. Mostly you don't want to be doing indexing on lists.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Debugging methods for haskell

[Jon Fairbairn]

Fernan Bolando fernanbola...@mailc.net writes:

 On Thu, Jul 16, 2009 at 4:10 PM, Jon
 Fairbairnjon.fairba...@cl.cam.ac.uk wrote:

 I wonder if your code has to use !! at all? I took a look at a random
 module from the above link, and (without making much attempt at
 understanding it), I'd guess that using accumArray and friends would be
 more appropriate. Mostly you don't want to be doing indexing on lists.

 Most of the !! are used to access a list of parameters similar to
 accessing structures in C.

Ah. I wondered why so many of them were x!!0. list!!constant is almost
always something that could be done better.

 I am not particularly sure how to apply accumArray for something like
 that?

You [probably] don't. My apologies for not looking more carefully (I
really did just glance at it), but the remark about not using !! still
stands. I've been trying to look at your source again, but the link
doesn't respond to requests at the moment, so I can't be much help.
Haskell has much richer mechanisms for doing structure-like things than
C. Tuples and data types being the most obvious.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Haskell Zippers on Wikibooks: teasing! :)

[Jon Fairbairn]

Matthias Görgens matthias.goerg...@googlemail.com writes:

 doesn't make much sense to me yet, although I suspect I can read the mu as a
 lambda on types?

 Not really.  The mu has more to do with recursion.

I'd say it's entirely to do with recursion. It's like the Y combinator
(or fix) for types, though it is combined with a lambda.

mu t . t is like fix (\t - t)

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

[Jon Fairbairn]

Wolfgang Jeltsch g9ks1...@acme.softbase.org writes:

 Am Freitag, 10. Juli 2009 05:26 schrieb rocon...@theorem.ca:
 I find it amazing that you independently chose to spell colour with a `u'.
 It makes me feel better about my choice.

 I have to admit that it makes me unhappy. :-( 

 Why do we use English for identifiers? Because English is the language
 of computer science. What English should we use? It’s tempting to say,
 we should use the original English, which is British English. But we
 should ask again what is the language of computer science. And the
 language of computer science is American English.

I don't buy that. And don't forget India.

 To my knowledge, most early developments in computer science had their roots 
 in the US.

Really? Manchester Mark I, EDSAC I, EDSAC II? Alan Turing, David
Wheeler, Maurice Wilkes? To mention a random selection of early ones
(leaving aside Konrad Zuse and colleagues and various Russian pioneers
on account of not speaking English).

 One consequence of this is that reserved words of programming 
 languages are typically in American English. PASCAL uses “program”,

The use of program rather than programme in programming was mandated
by the IFIP in what I regard as an attempt to act outwith their remit.
I've never accepted it.

 not “programme”, and BASIC uses “COLOR”, not “COLOUR”.

I'm not sure I would use BASIC as an authority for any aspect of
programming language design. Going back to the early developments
aspect, a high proportion of early work in functional programming was
done in Britain and elsewhere in Europe (at a time when Europeans
typically preferred British spellings), so perhaps one should recognise
that in choosing identifiers.

But anyway, where's the harm in a bit of variety? If someone who prefers
British spellings originates a package, why get het up about it if they
use them in identifiers? I have to put up with American spellings all
over the place, so a few British spellings might even up the balance a
bit.

-- 
Jón Fairbairn (British, but with a tendency to identify myself as
European)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: golf, predicate check function for MonadPlus

[Jon Fairbairn]

Dan Doel dan.d...@gmail.com writes:

 On Thursday 02 July 2009 6:36:09 am Jon Fairbairn wrote:
 check :: (MonadPlus m) = (a - Bool) - a - m a
 check p a
 | p a = return a
 | otherwise = mzero

 I've often noticed the need for a similar function in conjunction with 
 unfoldr:

   -- This is overly general for unfoldr, but it lines up with check
   stopAt :: (MonadPlus m) = (a - Bool) - (a - b) - a - m b
   stopAt p f x
 | p x   = mzero
 | otherwise = return (f x)

Yes, I've had occasion to use something like that too,
eg things similar to:

reverse . unfoldr (stopAt (==0) (swap  . flip divMod 10))
   where swap (a,b) = (b,a)

 And of course: check = flip stopAt id . not

or, equally, stopAt p f = fmap f . check (not . p)

Granted,

reverse . unfoldr (fmap (swap . flip divMod 10) . check (/=0))

isn't /quite/ as nice as the first version, but I imagine one could get
used to it.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] golf, predicate check function for MonadPlus (was Re: How to read safely?)

[Jon Fairbairn]

Dan Doel dan.d...@gmail.com writes:

 There was talk of adding a readMaybe a while ago, but apparently it
 never happened.

 As it is, you can use reads, read s becomes:

 case reads s of
   [(a, rest)] | all isSpace rest - code using a
   _  - error case

 which ensures that you have an unambiguous parse with only trailing
 whitespace. You can, of course, modify that if you don't care about
 ambiguity or trailing characters.

I was wondering about a more algebraic way of writing that; here's a
version (that doesn't care about ambiguity)

readMaybe :: Read a = String - Maybe a
readMaybe
= join . fmap no_trailing_garbage . listToMaybe . reads
  where no_trailing_garbage = fmap fst . check (all isSpace . snd)

check :: (MonadPlus m) = (a - Bool) - a - m a
check p a
| p a = return a
| otherwise = mzero


I tried Hoogling for a function like check, but couldn't find it. Surely
there's one in a library somewhere? It looks useful to me. (I'm rather
taken by way the check (all isSpace . snd) part reads)

Monad.guard comes close but fails to get the cigar; in fact 

guard b == check (const b) ()

So check is more general.


Also, I don't see a singletonListToMaybe that one could use in place of
listToMaybe to require unambiguity. Could do

isSingleton [a] = True
isSingleton _ = False

and then use listToMaybe . join . check isSingleton -- aha! Another
use for check!




 Jón


[Footnote: I thought of writing guard == flip (check . const) () but
then realised it was pointless]

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: (fwd) Haskell logo fail

[Jon Fairbairn]

Jason Dusek jason.du...@gmail.com writes:

   Why don't we have a picture of a cool dinosaur instead?

Something cool because the last heat of life went out of it
65 million years ago?

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Haskell philosophy question

[Jon Fairbairn]

Vasili I. Galchin vigalc...@gmail.com writes:

 Hello,

  I am confused between Haskell as delineated in the Haskell Report VS
 ghc pragmas which extend Haskell beyond the Haskell Report.

Pragmas are part of the report, and while I agree that using
them for extensions is stretching the meaning a bit, it's
clearly the best way of doing it -- they're not supposed to
change the semantics of the language as defined, but it
doesn't say anything about what they do to stuff that isn't
part of the language.

 I am sure I am not the first to ask. Caveat: on my part, I
 am not against innovation/extensions, but I don't like to
 see language bloat.

Me neither, but many of the extensions are for things that
hadn't been invented (or perhaps finalised, such as
heirarchical modules, IIRC) when the standard was written,
and which make the language more expressive, which is a
worthwhile aim. Among the stated aims of Haskell was to be a
platform for language development. Pragmas keep the
experimental stuff separate from the stuff one can rely on
because it's part of H98.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: fromInteger for Lists

[Jon Fairbairn]

Henning Thielemann schlepp...@henning-thielemann.de writes:

 Paul Keir schrieb:
 There's nothing better than making a data type an instance of Num. In
 particular, fromInteger is a joy. But how about lists?

 http://www.haskell.org/haskellwiki/Num_instance_for_functions
 http://www.haskell.org/haskellwiki/Type_classes_are_for_reusability

Hear, hear!

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: chr/ord?

[Jon Fairbairn]

Tim Wawrzynczak inforichl...@gmail.com writes:
 On Tue, Apr 28, 2009 at 8:08 PM, michael rice [1]nowg...@yahoo.com
 wrote:

   Hi,

   My Prelude docs must be out of date because chr and ord don't seem to be
   there. How do I access these functions?

 Michael, those functions are not in the Prelude, they're in Data.Char.

But they're not really necessary anyway:

   Prelude fromEnum 'A'
   65
   Prelude toEnum 42::Char
   '*'


-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release

[Jon Fairbairn]

Colin Paul Adams co...@colina.demon.co.uk writes:

 Lennart == Lennart Augustsson lenn...@augustsson.net writes:

 Lennart Of course, n+k will be missed by Haskell obfuscators.  I
 Lennart mean, what will we do without (+) + 1 + 1 = (+) ?

 I think what would be missed would you be having the opportunity to
 explain to me what it means.

It means the same as

(+) ((+) + 1) 1 = (+)

HTH c.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) --first release

[Jon Fairbairn]

Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com writes:

 Jon Fairbairn wrote:
 But we can remove them in future language versions. The point I was
 trying to make at the beginning of this subthread was that
 implementations should follow the definition, because having a core
 language (Haskell 98) that can be relied on is simpler and wastes
 less time than the alternative.

 There has to be a bit of give and take here between standards and
 implementations.

There is no such compulsion. There's an excellent case for
information from implementors and programmers to feed
experience into future standards, but that's not a reason
for implementing something part way.

 The Haskell 98 standard is now very old and becoming
 increasingly less relevant, hence the Haskell' effort.
 (n+k) patterns were always controversial and the decision
 to include them has indeed been reversed by the Haskell'
 committee.

But there is no retroactive removal from Haskell 98.

 So I would say that {Haskell 98 - (n+k)} is itself a
 worthwhile standard to implement.

It's not a standard. You have to document the difference
(waste of time), programmers have to notice the difference
(waste of time), books that describe H 98 no longer apply
(waste of effort). You can argue that the wastes here are
individually small, but you have to multiply them by the
number of times they happen (and again, I'm taking n+k as an
example of a general problematic attitude that's been with
us since FORTRAN I*, rather than really arguing about n+k
specifically).


[*] The FORTRAN IV standard contains some really quite
entertaining examples of what happens when you try to
standardise the intersection of divergent implementations of
a programming language.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release

[Jon Fairbairn]

John A. De Goes j...@n-brain.net writes:

 That's absurd. You have no way to access private source
 code, so any  decision on what features to exclude from
 future versions of Haskell  must necessarily look at
 publicly accessible source code.

This is all entirely beside the point. The question is not
whether n+k patterns should be in the language, it's whether
an implementation of Haskell 98 should include them.

 The only alternative is to continuously add, and never
 remove, features from Haskell, even if no one (that we
 know) uses them.

But we can remove them in future language versions. The
point I was trying to make at the beginning of this
subthread was that implementations should follow the
definition, because having a core language (Haskell 98) that
can be relied on is simpler and wastes less time than the
alternative.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release

[Jon Fairbairn]

Miguel Mitrofanov miguelim...@yandex.ru writes:

 Well, the problem is that every implementor does choose a
 subset of standart to implement.

That's what I'm complaining about.

 It's much worse in JavaScript - essential features working
 differently in Internet Explorer, Firefox, Opera, and
 Safari, and sometimes they even differ between versions; Web
 programmers still manage.

Strange example to choose. Have you any idea how much time
is wasted because of the implementation differences in
JavaScript? 

 (n+k)-patterns are nothing compared to that.

Since there is no need for /any/ differences in the
implemented part of H98, we can, if we choose, have /the/
language where all this crap about I'd better not use this
part of the standard because the MuckWorx compiler doesn't
implement it doesn't apply.

This thread is really depressing (this is about the rest of
the thread, not your post Miguel). We're rehearsing the
arguments about n+k patterns that were gone through by the
first Haskell committee and then rehashed by the H98 folks,
when that's completely irrelevant -- n+k patterns are in
H98, so implementors should implement them. It's arrogant
and disrespectful on the part of the implementors to say
that they know better than the committee what features
should be part of the language.

I'm reminded of decades ago when people talked about
implementing extended subsets of this or that language.
Perl is an extended subset of Haskell...

Concerning the suggestion that I should implement them,
given that I'm against n+k patterns, I hardly think the
effort should fall on me -- I'm not in the business of
implementing Haskell at all at the moment. Or maybe I should
be more pro-active. Here, using my favoured paradigm of
Advanced Reactive Software Engineering (a successor to
extreme programming and the like) is my Haskell 98 compiler
(currently only implements a subset):

module Main where
main = error (You have used an unimplemented feature of Haskell 98.\n\
  \Please submit a test case and patch to correct the deficiency\n)

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release

[Jon Fairbairn]

Achim Schneider bars...@web.de writes:

 Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote:

 a...@cs.uu.nl writes:
 
 Utrecht Haskell Compiler -- first release, version 1.0.0
 
 
 
  The UHC team is happy to announce the first public release of the
  Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell98
  features
 
 Why? Is there something about Haskell 98 that's hard to
 implement?
 
 Insanity. I doubt anyone is going to miss n+k patterns:

That (taken with the followup from Richard O'Keefe saying he
does use them) underlines my point, really. What follows is
specific to Haskell, but the general point applies to most
languages I've encountered.

I have no love for n+k patterns, but they are part of
Haskell98 -- and were the subject of protracted arguments
for and against them before the Report was finished (I was
against them, if I remember correctly). Any implementation
claiming to be of Haskell98 should have them, whether or not
the implementor likes them, because otherwise someone will
come along with a valid Haskell98 programme and it won't
compile, so they'll have to hack it around. This sort of
thing (and resulting #ifdef all over the place) wastes far
more programmer time in the end (assuming the compiler
becomes popular) than it would take to implement the
feature.

It's not an implementor's place to make such decisions --
they can legitimately say this feature sucks and tell the
next Haskell committee so. If they care enough about it,
they can lobby or get on that next committee, but the
arguments for n+k patterns /in Haskell98/ were done long
ago.


-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release

[Jon Fairbairn]

a...@cs.uu.nl writes:

   Utrecht Haskell Compiler -- first release, version 1.0.0
   


 The UHC team is happy to announce the first public release of the
 Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell98
 features

Why? Is there something about Haskell 98 that's hard to
implement?

 plus many experimental extensions.

fair enough, but it always puzzles my why implementations of
compilers almost never start with a complete standard
language.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Learning Haskell

[Jon Fairbairn]

Tom.Amundsen tomamund...@gmail.com writes:

 How long did it take you to become proficient in Haskell?

Something more than twenty years.

 By that, I mean - how long until you were just as
 comfortable with Haskell as you were with your strongest
 language at that time?

Oh, Haskell was my strongest language during all that time! ;-)

If I have a serious point, it's that going from writing
imperative programmes to writing properly functional ones
takes a lot longer than it takes to learn every facet of the
language.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Specific denotations for pure types

[Jon Fairbairn]

Conal Elliott co...@conal.net writes:
 Oh -- not one version of Int for 32-bit execution and another version for
 64-bit execution?  Seen on #haskell today:

   mux  maxBound :: Int
   lambdabot   9223372036854775807

I've always been opposed to having Int built in (in
contrast to having Int32 and Int64 defined in a library
somewhere). It's much cleaner to have Integer as the
language integer. A reference implementation of Int8 (for
brevity!) could be written with (off the top of my head)

data Int8 = Int8 !Bool !Bool !Bool !Bool !Bool !Bool !Bool !Bool

which would specify the semantics exactly.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

[Haskell-cafe] Re: Haskell Logo write-in candidate

[Jon Fairbairn]

Warren Harris warrensomeb...@gmail.com writes:

 Hi Jon,

 I agree with much of your rant, and would agree that the
 logo is  probably the least interesting about haskell, but I
 think that it's  worth spending a little time to spiffy up
 haskell's image from a  marketing perspective.

I don't disagree with that. I'm complaining about the
method...

 Although I downplayed much of my design decisions by
 focusing on the logo's t-shirt potential, I just wanted to
 say that a lot of thought did go into the design aspects
 of what I sent out.

I don't dispute that either. My point (about lack of
justification) was not that people didn't put thought into
their efforts, but that there's no mention of it on the
listing.


 A logo needs to be a crisp graphic, needs to draw people
 in who don't yet understand (pure lazy fun-- huh? or
 what's with that Amtrak symbol?)

That's where that particular design falls down. = is an
ugly symbol in the first place, and while the pun with a
lambda in the middle provides some intellectual
satisfaction, it doesn't outweigh the fussiness of its shape
or the irrelevant associations. I hadn't thought of Amtrak,
but it made me think of the flags of Mozambique and South
Africa.

 This is all off in the realm of marketing psychology,
 which is a far cry from programming language design, but
 important in the overall product perception nonetheless.

Again, I don't dispute the importance, but...


 The other thing about this logo design that is so great is
 the  community process that's creating it. It's the open
 source process in  a nutshell -- the brightest minds playing
 off each other to build  something bigger than the sum of
 the parts.

That could happen, but a vote by people who haven't been
given a clue isn't the way to get there.

 So even if the new logo ends up looking like something
 that rolled down hill collecting rubbish, the story behind
 it will be brilliant -- like a family photo reflecting who
 we are and how we do things here.

Maybe so, but the story isn't what's important as far as
your first point is concerned.

 I hesitated in sending my write-in candidate in the first
 place  because I didn't want to derail the process that's
 underway,

derailing it is necessary if we are to get the brightest
minds playing off each other

 Now at the risk of further muddling things, I'll just say
 that I like your idea of focusing on the :: symbol, and
 just wanted to provide my interpretation:

That design is more like it! I would vote for that.

 I think that's not bad either, although I think it loses a
 little of  the distinction and intrigue of Pollard's lovely
 monad/lambda symbol  with its curved edges.

In the absence of the :: version, I'd might go for that one,
but I think it really isn't simple enough, though to
properly decide between them, we'd have to try them out on
non-Haskellers.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Query on list comprehension

[Jon Fairbairn]

Richard O'Keefe o...@cs.otago.ac.nz writes:

 The problem we were asked about was specifically
 a
 aa
 aaa
 The code (iterate ('a':) \n) does not give the right answer.
 It's not just that it produces an infinite list instead of three
 strings, it doesn't even start with the right string.  It starts
 with \n when we need a\n.

It was impossible to determine that from the question.

 To produce the specified output using that pattern, you need
 (take 3 . tail . iterate ('a':)) \n

take 9, surely?

 or any of several other alternatives.

 The original poster also didn't ask what is the best way to do
 this, but specifically asked about doing it with list
 comprehension.  Presumably this was an attempt to understand list
 comprehension better.

Perhaps, but as the OP didn't follow up to the message where
I said that it wasn't clear what the question was, by the
time Henning posted, I think he was justified in
generalising the question and taking the answer further.
This café is for discussion; it's not a suitable place for
asking a question, copying out the answer and disappearing
without further comment.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe