On Jan 23, 2013 11:03 PM, "Alan Manuel Gloria" <[email protected]> wrote:
>
> Offside rule simply looks at the column of the first non-{ token after
> keywords "do", "let", "of", and "where", and memorizes that column,
> inserting the missing "{". Tokens starting at that column will have a
> ";" inserted before it (basically, ending the previous expression),
> and tokens starting at columns to the left of the off-sided column
> will end the off-siding (inserting a "}" to end it).
>
> So for example:
>
> > do ! x
> > ! y
> > bar
>
> Gets translated to:
>
> > do ! {x
> > ! ;y
> > }bar
>
> So basically, Haskell implicitly supports the "bullet" style, but can
> admit the "header" style.
>
> In practice, most Haskell code is in "header" style.
>
> *Technically* the name of the rule "offside" refers to the fact that
> inner elements should be to the *to the side of and below* their
> parent keyword (i.e. think a strict combination of the "bullet" and
> "header"). The requirement to be to the "side" was relaxed in Miranda
> (and eventually Haskell), but the rule remained "offside".
>
> By my memory the original offside rule (below and to the right,
> strictly) is the first time that anyone formalized indentation-based
> program organization.
>
> In practice, Haskell can support either "header" or "bullet" because
> only some keywords support indentation formatting(function
> applications in Haskell *must* be grouped by parens or infixes, so you
> can't use indent to denote boundaries of function arguments).
>
Thanks for the explanation.
> >...
> Here's an even bigger deal-breaker: it makes parent structures harder
> to modify, because if the length of the parent is changed (for example
> inserting an argument you forgot in the first pass of writing the
> code, or modifying an existing function to accept a new argument, or
> adding some logging code, or whatever) then you have to re-indent all
> the children.
>
Indeed. This doesn't prevent it being used in languages with parens, but
those allow you to edit freely and then have the editor fix the indentation.
I agree now that opening several levels on same line - let's call this
"bullet bullet" - is too fragile and a bad idea.
(This wasn't obvious to me a couple days ago when I started that long
mail...)
But I still
> This is the main reason why Miranda and Haskell relaxed the "to the
> right" part of the original offside rule.
>
> > And of course I can use | many times on a line:
> >
> > | let | | x | cos a
> > ! | y | sin a
> > ! body-of-let ...
>
> Err I think this would be better off as:
>
> > | let | | x | cos a
> > ! ! | y | sin a
> > ! | body-expr-of-let
> > ! | body-expr-of-let-2
>
> what you think?
>
Absolutely, the "! body-of-let" in my example was wrong.
> > So far so good, but what about "header" style?
> >
> > | defun f | a b c
> > ; note BTW how the second | above consumes
> > ; only a b c, not the whole body as $ a b c would do.
> > | cond
> > | condition1
> > | let
> > | | x | cos a
> > | y | sin a
> > body-of-let...
> > | condition2
> > body2...
> >
> > Again, I'd like defun, cond, let to stand out better.
> > This would look mildly better if I allow deeper indentation than
required:
> >
> > ; in scheme: define| f| a b c - similar to
> > ; defun f (a b c) vs. define f(a b c)
> >
> > | defun f | a b c
> > | cond
> > | condition1
> > | let
> > ...
> >
> > But this is merely lisp with s/(/| / and s/)//!
> > And all the leading | are still distracting.
>
> And it's not half-bad IMO, actually.
>
I actually don't like it much :-)
It was interesting to me as "simplest thing that could possibly work", but:
- I actually do like the auto-listification of "foo bar".
Having to prepend each line with | would annoy me.
I think my proposal of postfix "foo| bar" was mostly a way to hide from
this fact...
- There is no way to undent (without $).
> I take it that postfix f| means something like n-expression f(?
>
> So:
>
> define| f| a b c
> body| x
>
> ==>
>
> define( f( a b c ) ; closing parens inserted
> body( x ) ; closing parens inserted
> ) ; closing parens inserted
>
> ==>
>
> (define (f a b c)
> (body x)
> )
>
Yes, precisely.
For some reason the "foo|" == "| foo" equivalence feels very cheap to me,
more so than "foo(" == "(foo". Probably because "foo(x)" is already a
familiar syntax.
> --
>
> Practical problems:
>
> 1. In Common Lisp, "|" is used to denote symbols with "special
> syntax", i.e. (symbol "foo bar") => |foo bar|.
>
Yeah, I remembered that minutes after sending the mail.
Anyway, this was just an exercise.
> 2. Supporting "| defun foo | a b" requires knowing how wide
> characters are (CJK width problem), especially if you can do something
> like:
>
> | defun foo | &key
> | ! | var1 | default-value 'var1
> ...
>
Yeah. I'm giving up on "bullet bullet" which requires char counting.
I still wish for a way to make a bullet-style call or list where the first
line is handled like the others.
Neither this
f a \\ b
! c \\ d
! e \\ f
;; results in (f a) (b c d e f).
nor
f \\ a b
! ! c d
;; results in f (a b (c d))
is anywhere close to what I want.
But it's fine as long as I use one element per line.
This actually works semi-nicely for let:
let
! \\ x{cos(x)}
! ! y{sin(x)}
! foo x y
Turns out I haven't done my homeworks - for let that's already a FAQ in the
draft SRFI, and what I want has been discussed extensively as "ENLIST"!
I'm off to read all those discussions...
Overall I'm becoming comfortable with the existing semantics of \\ and $
for writing code.
I'm less comfortable *reading* code with \\. It's fine when used
idiomatically, but its corner cases can be *very* surprising.
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Readable-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
