> Jon,
>
> I think many of the questions relating to your layout query are
> covered by sentence 763 at:
>
> www.knosof.co.uk/cbook/cbook.html
Thanks. A bit
> You might also like to look at Section 9.1 "C culture and
> developer knowledge" of sentence 1. This covers categorization
> issues and implicit learning that I think is relevant to your queries.
>
> >In the programming language Haskell, layout (indentation) is
> >used as an alternative to begin/end (actually {/})
> >bracketing and semicolons.
>
> Occam is the only other language I know that has this property.
Well, the following languages also have it:
Miranda (D Turner), Orwell (P Wadler), Clean (Plasmeijer and
van Eekelen). All of these take the idea from Landin's
"offside rule" in "The next 700 programming languages" (CACM
1966). And as mentioned elsewhere, Python. I'd be surprised
if there were not others.
> I suspect it derives more from mathematicians delight in minimalism
> than good language design practice.
No, I don't think so. Our motivation in using it in Haskell
was that programmers generally lay out programmes to reflect
the structure, and can be misled by this. In something like
do { something1;
something2;
do { something else;
some other thing;
and yet another;
and another}}
the tendency is to read it as if the first closing brace
were on the fourth line.
> >do thing1
> > thing2-p1
> > <op> thing2-p2
> >
> >comes out as do {thing1; thing2-p1} <op> thing2-p2
> >
> >and I think that's really bad, because "from a visual
> >perspective '<op> thing2-p2' is perceived as being at the
> >same 'level' as thing1 and thing2-p1"
>
> After trawling what studies I could find, the conclusion I
> came to was that issues such as this were driven by higher level
> cognitive processes (which require effort), not the lower automatic
> ones (which don't appear to be effortless).
>
> My other conclusion was that what developers considered to
> be 'natural' were those constructs they had lots of experience with.
> I would claim that your preferences are derived from what you have
> learnt from reading Haskell (and other languages) source code.
Quite possibly, but that's hardly material. We are
concerned with what kind of misreading someone who is used
to the language will tend to make. Besides, some of the
prior experience is of reading ordinary text, where bulleted
or numbered lists typically use indentation to indicate
nesting. What we want is for the effects of the cues to
match the expectations.
> >It's this quoted statement for which I need some sort of
> >theoretical support.
>
> I think you are simply a creature of your past experiences.
I think we all are. But the experiences of Haskell
programmers will be of Haskell programmes. I don't know
anything like enough about the psychology to express what I
mean, but it seems to me that the learning of layout rules
can modulate but not completely override lower-level issues,
so in designing the layout rule we have a certain amount of
freedom, but if we push it too far, then misreadings will be
more frequent even in experienced programmers.
> I think there will be sufficient creatures, having
> different past experiences, who take the opposite view,
> that there is nothing to be gained from choosing one way
> or the other.
I'm not sure what you mean by "opposite view" here.
> The paper by Quinlan discussed in sentence 763 (see figure 6) found
> a 50/50 split of the population, in how items were grouped.
Figure six doesn't look to me like the case under
consideration. From my limited grasp of the terminology, I'm
very surprised if the corners formed by the changes in left
margin in
adslfja asfa a as
asdfkaf asdffsad
asdflkjsdfa asf
asdfkasdf afsddfsaf
asdflkjdfa asf
asfdlka
asdfkljfsa
asdffsad afsfassf
asfdfdasfd
safdsadf
are not located by pre-cognitive processing. Is that really
the case?
If it is, then we still have it that haskell programmers
will learn that basic property of the layout rule, and my
suspicion is that the current exceptions to the rule to
allow same-line closing of nestings are a bad choice.
J�n
--
J�n Fairbairn [EMAIL PROTECTED]
31 Chalmers Road [EMAIL PROTECTED]
Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!)
- Automatic footer for [EMAIL PROTECTED] ----------------------------------
To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss
To join the announcements list, mail [EMAIL PROTECTED] subscribe announce
To receive a help file, mail [EMAIL PROTECTED] help
This list is archived at http://www.mail-archive.com/discuss%40ppig.org/
If you have any problems or questions, please mail [EMAIL PROTECTED]
