
On Mon, 2002-08-26 at 11:33, Simon Marlow wrote:
Allowing characters to span more than one column wouldn't break the layout rule, as long as the character to column mapping is generally agreed upon across editors and locales. (I think we established that this is not necessarily the always case, although in practice it should be).
I guess we can just refer to the Unicode standard for the mapping?
Requiring a newline before a new layout context would break *a lot* of code. You can't write 'let x = 42 in x + 1' for example. Sure, a refinement could be made to allow these kind of things, but this will serve to make the layout rule more complex, rather than less. So to extend gracefully while keeping backwards compatibility, I propose:
- There be a fixed character->column mapping
I agree.
- Tab stops are every 8 columns
This appears to be the only viable solution if we don't want to force layout blocks to start after newlines, your argument against which I accept.
- We recommend that programmers avoid using indentation levels which depend on the widths of non-space characters.
Obeying the third requirement means that your code will look fine in a proportional font. The compiler could warn about violations quite easily. Note that it is ok to write 'let x = 42 in x + 1', because the meaning of the code doesn't depend on the actual indentation level of the first 'x'.
Good point, I'd be happy with it. Regards, Sven Moritz

On Mon, Aug 26, 2002 at 12:19:14PM +0200, Sven Moritz Hallberg wrote:
On Mon, 2002-08-26 at 11:33, Simon Marlow wrote:
Allowing characters to span more than one column wouldn't break the layout rule, as long as the character to column mapping is generally agreed upon across editors and locales. (I think we established that this is not necessarily the always case, although in practice it should be).
I guess we can just refer to the Unicode standard for the mapping?
It's not part of the Unicode standard, but see http://www.unicode.org/unicode/reports/tr11/ Note that there's a special category for "East Asian ambiguous", which could not be sensibly assigned a width. Personally, I'd vote for making it an error to write something like
x = y where y = z z = 5
and add a compatibility mode to compilers. The Haskell standard doesn't have a notion of "warnings", does it? --Dylan
participants (2)
-
Dylan Thurston
-
Sven Moritz Hallberg