[racket-dev] Code micro-level organization

I was clapping through the majority of your email.

I want define* so bad.

I use compose and curry a lot (even though I know their performance
problems) because it don't have to name things.

I like the idea of the -> thing with the down and up arrows. I see a
value in both arrows. I also like Jon's suggestion of a 'last' id...
although I'd also want <0> through <n> or something to refer to so
many spots back.

Jay

On Wed, May 30, 2012 at 3:40 PM, Eli Barzilay <eli at barzilay.org> wrote:
> I'm going to ramble a bit about organizing code, trying to look for an
> idea for a good solution -- so spread a few kgs of salt over the
> following (if you care to read it).
>
> The problem that I'm talking about has several manifestations.  The
> most obvious one is code-drift towards the RHS.  A less obvious
> problem is how it's sometimes hard to read code.  To use a cooked up
> example:
>
>  (let ([str (string-trim (substring "foo bar baz" 3 8))])
>    (and (regexp-match? #rx"^[a-z].*[a-z]$" str)
>         (string-append "*" str "*")))
>
> to read this, you start from the string literal, then read the
> `substring' expression, then `string-trim', then the `let' binding,
> then the `and' and finally the `string-append'[*].  To relate this to the
> above: besides the right-drift (which is of course very minor here),
> it takes time to "internalize" the rules of the language that leads to
> this, which is a problem for people new to functional programming with
> it's heavy use of nested function calls.  More than that, I think that
> it's also a problem for *experienced* hackers too -- to see what I
> mean, open up any random piece of code that deals with an area you're
> not familiar with, and try to read through it.  Personally, I often
> find myself in such situations "reading" the actual ordering as I go
> through the code, and that's fragile since I need to keep mental
> fingers at various locations in the code in question, sometimes even
> using my real fingers...
>
> You'd probably recognize that there's a whole bunch of tools that are
> trying to make things better.  A few random ones that I can think of
> are:
>
>  * The new semantics & blessing for using `define' forms instead of
>    `let' etc makes code easier to read and avoids some right-drift.
>
>  * There's the need (which I recently talked to at NEU) for some kind
>    of a `define*' form that can be used as a definition with a `let*'
>    scope.  For those who weren't there, the summary of the issue is
>    something that Jay once said -- that he sometimes uses
>      (define x0 ...)
>      (define x1 (... x0 ...))
>      (define x2 (... x1 ...))
>    because he wants to avoid a `let*'.
>
>  * The old `scheme/nest' is a direct attempt to prevent drift for
>    some kinds of nestings.
>
>  * There's the related suggestion for extending the reader with
>    something like `$' or `//' that closes the rest of the sexpr in
>    its own set of parens.
>
>  * Every once in a while there's a suggestion to invert conversion
>    functions, eg, turn `string->number' into `number<-string' so it
>    reads out better.  In a similar direction, there are sometimes
>    suggestions to use `compose' to make things more readable, as in
>      ((compose f1 f2 f3 f4) x)
>    vs
>      (f1 (f2 (f3 (f4 x))))
>    and the textual mess that the latter tends to end up as with real
>    names.
>
>  * srfi-2 defines an `and-let*' which is addressing a common pattern
>    of interleaving nested `let's and `and's.  Actually, `cond' itself
>    is addressing this kind of problem too, so add here various
>    suggestions for extending `cond' with binders, anaphoric forms
>    etc.
>
>  * Recently, I looked at some clojure pages (to hunt for new
>    extensions to `racket/list'), and I saw that they have a
>    "threading form" using `->' that expresses nested function calls.
>    See this here:
>      http://clojuredocs.org/clojure_core/clojure.core/-%3E
>    and note also the other three variants, `->>' `-?>' and `-?>>',
>
>  * (The list goes on...)
>
> (One common theme in all of these is that they're tools that none of
> them are tools that are needed -- they're all just ways to make code
> look better.)
>
> I actually started thinking about this when I saw the clojure thing.
> The first thing that is limited about it is that it has four forms,
> where the reason for the `->' vs `->>' split is to put the nesting in
> a different argument position.  To summarize (and IIUC):
>
>  (-> x
>      (foo 1 2)
>      (bar y))
>
> expands to
>
>  (bar (foo x 1 2) y)
>
> whereas using a `->>' would make it expand to
>
>  (bar y (foo 1 2 x))
>
> Not only does it seem to me bad to have two bindings for this, we also
> have the usual problem of the order-defying `regexp-replace' where
> usually the action happens in the *middle* argument...  (Which is how
> it ends up being a common example in showing these problems, as
> happened recently.)
>
> In any case, this looks like an easy thing to fix by adding an
> explicit marker to the point where the nesting happens.  For example,
> imagine a form that looks like this:
>
>  (○ x
>     (foo 1 <> 2)
>     (bar y <>))
>
> that expands to (bar y (foo 1 x 2)).  (The reason that clojure has two
> other forms (`-?>' and `-?>>') is something that is related to the
> below, so I'll skip it for now.)
>
> The next thing that I tried is to contrast this with `nest'.  The
> difference between them is that while both lead to a simpler syntax
> for nested expressions, they do the nesting in different directions,
> where (*very* roughly speaking) `->' nests things downwards and `nest'
> nests them upwards:
>
>  (-> X Y)    nests X into Y
>  (nest X Y)  nests Y into X
>
> or more generally:
>
>  (-> X Y0 Y ...) nests X into Y0 and nests the results with Y ...
>  (nest X Y ...)  nests the result of nesting Y ... into X
>
> So I tried to see if I can come up with something that can kill both
> birds -- which is why I started with the above example:
>
>  (let ([str (string-trim (substring "foo bar baz" 3 8))])
>    (and (regexp-match? #rx"^[a-z].*[a-z]$" str)
>         (string-append "*" str "*")))
>
> Now, lets imagine that instead of a simple `<>' hole, there are two
> kinds of holes with an "up" or a "down" direction -- this leads to
> this kind of a syntax:
>
>  (○ "foo bar baz"
>     (substring ↑ 3 8)
>     (string-trim ↑)
>     (let ([str ↑]) ↓)
>     (and (regexp-match? #rx"^[a-z].*[a-z]$" str) ↓)
>     (string-append "*" str "*"))
>
> where you can read `↑' as "the above" and `↓' as "the below".  The
> thing that makes me excited about this is how you can read this as the
> above [*] reading.
>
> There are still some problems with this though.  One problem is that
> it can be ambiguous -- for example, I had this as one experiement:
>
>  (○ (let ([str "foo bar baz"]) ↓)
>     (substring str 3 8)
>     (string-trim ↑)
>     (string-append "*" ↑ "*"))
>
> where the upward nesting could happen first -- this ambiguity is easy
> to resolve if there's a simple rule for merging the first two
> expressions repeatedly, stopping with an error if there's not exactly
> one down arrow in the first or one up arrow in the second; and
> finishing when there's one expression (throwing an error if it still
> has arrows).  Using this, the expansion of the above goes with these
> steps:
>
>  ... ->
>  (○ (let ([str "foo bar baz"]) (substring str 3 8))
>     (string-trim ↑)
>     (string-append "*" ↑ "*"))
>  ->
>  (○ (string-trim (let ([str "foo bar baz"]) (substring str 3 8)))
>     (string-append "*" ↑ "*"))
>  ->
>  (○ (string-append "*" (string-trim (let ([str "foo bar baz"]) (substring str 3 8))) "*"))
>  ->
>  (string-trim (let ([str "foo bar baz"]) (substring str 3 8)))
>
> It's also unclear if this is generic enough though.  I vaguely suspect
> that there might be cases where you want arrows from multiple places
> in the form which makes this a kind of a literate-programming-like
> tool for micro-level code organization (and yes, I intensely dislike
> LP, so that's would be a bad thing).  In addition, something like this
> should really have simple rules for how it works, otherwise it not
> something that anyone would want to use or read.
>
> BTW, I take the `nest' experiment as an example: the form itself is,
> IMO, perfectly fine, but it suffered from having too much parentheses,
> which makes it hard to use.  One thing I like in the above is that the
> explicit arrow markers make it much easier to read -- I think that
> this is also an advantage over the clojure threading forms, where you
> see a form like (take 10) and you have to look back at the arrow kind
> that was used to know what this really is.
>
> In any case, any thoughts about this?  I'd especially appreciate
> little code layout horrors you might encounter, to see how such a form
> can deal with them.  Feel free to reply off-list to avoid premature
> bike-shedding.  (I'm *not* going to commit anything -- this is just
> trying to roll around the idea to see if there's any point in doing
> something like this.  *If* there is enough interest, then I'll post a
> concrete suggestion when I have one.)
>
> --
>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                    http://barzilay.org/                   Maze is Life!
>
> _________________________
>  Racket Developers list:
>  http://lists.racket-lang.org/dev



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93