Subject: Re: AW: Editor Tab Expansion - msg#00054

Previous Message by Date: click to view message preview

Re: AW: AW: Editor Tab Expansion

I think I was a bit inflamatory in my previous post because I was fuming about something else in my life; I stand by the factual content of what I said but wish I'd phrased it much less confrontationally. On Mon, 9 Dec 2002, matt hellige wrote: [snip] > > You seem to be saying that layout should > > be banished because there's a set of people (of undetermined size) who > > would like Haskell were they to encounter it, except for that darned > > optional layout rule interefering with the ability to choose a personal > > interpretation for what the ASCII tab character should mean. > > > > please do not discount this argument. the group of people who are, for > one reason or another, not members of the haskell community is not a > vocal group, nor are they well represented. however, they are the > majority. if there is interest in promoting haskell among those who > currently don't use it, which there seems to be, some time needs to be > spent either soliciting opinions from people outside the haskell > community, or guessing what those opinions would be. The point I was trying to make was that I'm not sure how big the block of poeple for whom the big problem is layout. I've supervised lots of undergraduate labs and found many people who absolutely don't like Haskell for many reasons, but I can't say I've encountered anyone for whom the layout rule was part of the reason for dislike; the biggest one was always that they never seemed to develop a mental model of programming functionally rather than in the procedural, variable based way they were used to. (Almost everyone had a steep learning curve deciphering how error messages involving missing semi-colons map to bad layout, but after a while it wasn't the layout that they gravitate to as the thing they have issues with.) I'd just about be able to accept elimination of the layout rule syntax for Haskell if there was evidence that it's a significant problem that stops Haskell being adopted. But given that I feel layout is a _really_ good thing this has to be _established in a meaningful way_, not just plucked out of the air on the basis of a a couple of opinions. > clearly, it's a tough thing to do well. many of the opinions of people > who aren't using haskell now may not be particularly relevant to the > future direction of the language. however, it they're completely > ignored, the language may never be accepted. this is the dilemma of > all software designers, and only those who have no need for actual > users can afford to ignore it. Certainly (with the slight proviso that I'd specify `informed, considered opinions'). ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/ | `It's no good going home to practise email:tweed@xxxxxxxxxxxxx | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh

Next Message by Date: click to view message preview

Re: Error Handling

On 10 Dec 2002, Alastair Reid wrote: (snip) > To do this, we have to actually build the set of all exceptions that > an expression could raise. This could take quite a while to build Why? I can see that, to do the ordering, you may want to know all the exceptions that can arise somewhere in the program, not minding about a few false positives. Then, at runtime, if an exception pops up, we just evaluate the other "parallel" expressions to see what else happens. Even if we do need the exact set of all exceptions that a particular expression could raise, could that be found at compile time? (snip) > And even this wouldn't get rid of the monads since the problem monads > deal with is present even if we can't observe the exceptions. For > example, a simple operation like this: > > choose :: a -> a -> a > > which returns its first argument if it can evaluate its argument to > WHNF without raising an exception and returns its 2nd argument > otherwise has severe semantic problems. I don't understand why, I'm afraid. I'm not sure if I'm missing something obvious or if we're somehow talking at cross-purposes. It probably doesn't help that I can imagine what it means to evaluate the first argument strictly but I'm having difficulty figuring out what Weak Head Normal Form is in relation to what Haskell code might get up to. I seem to have a problem understanding exactly how mathematical things shore up practical computing things even when I understand each in isolation, though. Of course, I am happy to suspend judgment until I understand your point better, and I don't think that you have any obligation to bring my education to the point where I can understand it! -- Mark

Previous Message by Thread: click to view message preview

Re: AW: Editor Tab Expansion

[Glynn Clements <glynn.clements@xxxxxxxxxx>] > > matt hellige wrote: > > > there seems to be an awfully strong bias against using hard tabs with > > a configurable displayed width. i'd like to describe a situation where > > i believe that option makes a lot of sense... suppose you're working > > on a team of programmers on a project, and you need to come up with > > some coding standards, since you all agree that's a wise thing to do. > > no suppose 40% of the programmers like a 4-space indent, 40% like a > > 2-space indent, and the other 20% like an 8-space indent. what to do? > > You decide upon a single style by whichever system you consider > appropriate (company policy, team vote, team leader's discretion, > etc), then require everyone else to follow it. If someone refuses to > accept common coding standards on an issue as simple as formatting, > the team is likely to be better off without them. > > This doesn't just apply to commercial development, either; even OSS > projects will reject code which doesn't meet their formatting > criteria. sure. i agree that coding standards are important. if they weren't, clearly it would be a non-issue... my supposition here is that you want to find a style that pleases as many programmers as possible. i see no reason to be intentionally frustrating... ;) > > cvs always sees the same thing, and we're all happy. obviously, this > > only works if indentation is used ONLY to indicate nesting depth and > > NEVER to align text vertically at some specific column. > > That's a pretty big if. It's quite common to use tabs for aligning > code or data which has a tabular form, i.e. multiple consecutive lines > with a common overall structure (e.g. repeated calls to the same > function with different actual arguments, array/list initialisers, > etc). sure. in many cases it won't work, which is why, at my last job, we settled on four spaces per indent, and eschewed tabs entirely. which still doesn't mean that that's the One True indentation style! m -- matt hellige matt@xxxxxxxxxx http://matt.immute.net

Next Message by Thread: click to view message preview

Re: AW: Editor Tab Expansion

matt hellige <matt@xxxxxxxxxx> writes: > I would > PREFER if haskell enforeced a strict distinction between spaces and > tabs for layout purposes, i.e., this: > let x = y > ^I z = q > ^Iw = l > in ... > should be an error. Simon¹ is usually very positive to adding enhancements, if this really turns out to be a problem, I propose that you ask for e.g. -fno-tabs : indentation with tabs is an error, only spaces allowed -fconsistent-indent : indents must be exactly matching in a block or whatever floats your boat, and helps you enforce your particular coding standard. Extra credit if you supply the patch to GHC, of course. :-) -kzm ¹ Haven't used the other compilers as much, but it's not my impression that they are any less open to persuasion. -- If I haven't seen further, it is by standing in the footprints of giants