On Fri, 09 Jul 2010 10:07:06 -0400, you wrote:

I don't think I've ever seen them *followed* by commas. Preceded, always.

In American English, they're always followed by commas, and preceded by comma, semicolon, dash or left parenthesis, depending on the specific context. Examples from various online style guides: I am the big cheese, i.e., the boss. The department is unattached; i.e., it is not administered by one of the schools or colleges. Most committee members—-i.e., those who were willing to speak out-—wanted to reject the plan. Most committee members (i.e., those who were willing to speak out) wanted to reject the plan. See also: http://www.videojug.com/film/how-to-use-ie-and-eg -Steve

On Fri, 9 Jul 2010 17:14:31 +0200, you wrote:

One of the "nice" things about English is that there is often never an "always." See http://grammar.quickanddirtytips.com/ie-eg-oh-my.aspx for a discussion.

Well, that page pretty much confirms what I said. In AMERICAN English, they're always followed by commas. The two sources mentioned on that page that suggest omitting the commas (Fowler's and Oxrford) are both based on UK English. -Steve

I don't know what the rule is, but I personally just replace "i.e." with "that is" and "e.g." with "for example" in my head, and then apply whatever punctuation makes sense with those substitutions. Cheers, Greg On 7/9/10 12:17 PM, Sean Leather wrote:

On Fri, Jul 9, 2010 at 18:35, Steve Schafer wrote:

On Fri, 9 Jul 2010 17:14:31 +0200, Sean Leather wrote: >One of the "nice" things about English is that there is often never an >"always." See http://grammar.quickanddirtytips.com/ie-eg-oh-my.aspx for a >discussion.

Well, that page pretty much confirms what I said. In AMERICAN English, they're always followed by commas. The two sources mentioned on that page that suggest omitting the commas (Fowler's and Oxrford) are both based on UK English.

And yet most of the other manuals describe the rule as "usually," "preferable/optional," and "makes good sense." That refutes your claim that "they're always followed by commas." ;)

Sean

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

On Sat, Jul 10, 2010 at 12:12:15AM +0200, Julian Fleischer wrote:

...

8. [...] Saying 0**0 is undefined seems reasonable, but why 0**y? I agree on 0**y being 0 (not undefined), but why should 0**0 be undefined? x**0 := 1, by convention. Of course this is a still ongoing debate (regarding analysis of functions etc.), but the most usefull approach for /any/ programming language (and BTW for many mathematical proofs, too).

Hi Julian, Glad somebody responded about something other than e.g. and i.e. I wasn't arguing that 0**0 *ought* to be undefined, but that it is a reasonable policy, since, as you point out, it's a matter of ongoing debate. What I don't understand is why for y /= 0, 0**y would be undefined. Maybe the discontinuity at zero is undesirable. Alex

On 16:21 Fri 09 Jul , John Meacham wrote:

I would think it is a typo in the report. Every language out there seems to think 0**0 is 1 and 0**y | y /= 0 is 0. I am not sure whether it is mandated by the IEEE standard but a quick review doesn't say they should be undefined (and the report mentions all the operations with undefined results)

IEEE 754 has three different power operations. They are "recommended" operations, which means that supporting them is optional. pown only allows integral exponents, and the standard says the following: pown (x, 0) is 1 for any x (even a zero, quiet NaN, or infinity) pow handles integral exponents as a special case, and is similar: pow (x, ±0) is 1 for any x (even a zero, quiet NaN, or infinity) powr is defined as exp(y*log(x)). powr (±0, ±0) signals the invalid operation exception [NB: this means that the operation returns a quiet NaN]. In C, the "pow" function corresponds to the "pow" operation here, assuming the implementation conforms to annex F of the standard (an optional feature).

Hi wren,

>> x**0 := 1, by convention.
> [...]
> So far as I'm aware, the x**0=1 vs 0**y=0 conflict leads to 0**0 [being] undefined
x**0 is 1 /by definition, 0**y naturally is 0, since (for example) 0**2 expands to 0*0 (being 0 of course). So there is not a conflict of two definitions, it's simply a definition somehow /overriding/ the natural attempt. I guess I'm actually messing things up using the word "natural" - how can "expand the multiplication of zero with itself zero times" be natural?

> [...] more helpful in mathematics.
> 
Try it yourself:
* Prove the binomial theorem *without* the convention 0**0 := 1
* Consider the function f(x) := x**0 - is it continuous (over the set of natural numbers including zero)?

Donald E. Knut writes on the issue [1] (see page 6 of the generated output), defending the position x**0 being 1.

Further: C99, Java define it that way. GHC does it that way.
Standard Prelude of Haskell 98 Report defines ^ (** for natural numbers) as "x ^ 0 = 1" [sic]
The convention is also used in 6.4.3: "The value of x^0 or x^^0 is 1 for any x, including zero" [2]

I know it's about "^" in that section, but why should x^0 be 1 and x**0 be undefined? (or: is the natural zero not the real zero?)

greetings,
Julian

[1] http://www-cs-faculty.stanford.edu/~knuth/papers/tnn.tex.gz
[2] http://www.haskell.org/onlinereport/basic.html#sect6.4.3

On Jul 11, 2010, at 9:20 PM, Daniel Fischer wrote:

...

* Prove the binomial theorem *without* the convention 0**0 := 1

Except that in the binomial theorem, one uses (^) and not (**). For (^), setting x ^ 0 = 1 is, as far as I'm aware, uncontested.

This is not so: the exponent in the binomial theorem is a real number, not an integer. See http://mathworld.wolfram.com/BinomialTheorem.html Real numbers turn up in surprising places. I imagine most of us are familiar with the derivative operator D, and with iterations of it like second derivatives. But it's not just natural number powers of D that make sense; there are fractional derivatives, and D**(1/2) does find uses.

Brandon S Allbery KF8NH writes:

On 7/8/10 22:25 , Alex Stangl wrote:

...

1. I.E. and e.g. should be followed by commas -- unless UK usage differs from US standards. (Page 3 and elsewhere, although FFI chapter

I don't think I've ever seen them *followed* by commas. Preceded, always.

Agreed. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Christopher Done wrote:

On 10 July 2010 01:22, Ivan Lazar Miljenovic wrote:

...

Brandon S Allbery KF8NH writes:

...

On 7/8/10 22:25 , Alex Stangl wrote:

...

1. I.E. and e.g. should be followed by commas -- unless UK usage differs from US standards. (Page 3 and elsewhere, although FFI chapter I don't think I've ever seen them *followed* by commas. Preceded, always.

...

From The Haskell 98 Library Report:

...

partition takes a predicate and a list and returns a pair of lists: those elements of the argument list that do and do not satisfy the predicate, respectively; i.e., [...]

I don't think you should bother nitpicking about commas here. As Gregory said, anywhere there is "i.e.", you can substitute it for "that is". Consider if the spec. was written with "that is" instead of "i.e.", would you then criticise where and where not commas are used? Does this arbitrary prescription really matter?

This is LaTeX folks! All prescriptivism can be solved by judicious use of macros. Honestly, for dealing with all the different journals' style guides, stuff like this should be standard fare for mere punctuation differences: \NeedsTeXFormat{LaTeX2e} \ProvidesPackage{latin}[2010/07/09 resolve style disputes] \RequirePackage{xspace} \newif\if@comma \@commatrue \DeclareOption{comma}{\@commatrue} \DeclareOption{nocomma}{\@commafalse} \ProcessOptions % According to most style guides we should not italicize common % Latin, since it needlessly draws attention to unimportant text. % For declarativity we specify this command so that clients can % choose to italicize if desired. \newcommand{\latin}[1]{#1} \newcommand{\.}{% Or choose another name if you please \if@comma .,\xspace \else .\, \fi } \newcommand{\Cf}{\latin{Cf}\.} \newcommand{\cf}{\latin{cf}\.} \newcommand{\Eg}{\latin{E.g}\.} \newcommand{\eg}{\latin{e.g}\.} \newcommand{\Ie}{\latin{I.e}\.} \newcommand{\ie}{\latin{i.e}\.} -- Live well, ~wren

On Wed, Jul 14, 2010 at 12:10:48PM +0100, Simon Marlow wrote:

it is returning undefined:undefined:undefined, which is different from [undefined,undefined,undefined].

My mistake. I should have read more carefully.

...

25. In section 41.4.4, bullet before isPermissionError isn't rendered correctly.

I can't see that - perhaps it has been fixed already.

Check the failure codes for hSeek. It was still there in the HTML version, at least, when I checked this morning. Thanks, Alex