[racket] Size matters

From: Eli Barzilay (eli at barzilay.org)
Date: Tue Jun 11 13:33:36 EDT 2013

On Saturday, Sean Kanaley wrote:
> 
> [...] Expanding from this, there is a sort of scope at work one
> might call "meaning or type scope". [...]

Yeah -- a "mental scope", referring to things that are "obvious" or
"visually obvious" when you look at code and usually focusing on small
chunks when you do so.  It's also why lexical scope works way better
than dynamic scope, and why de-bruijn indices fail for most human
purposes...


An hour and a half ago, Matthias Felleisen wrote:
> On Jun 10, 2013, at 8:18 AM, Tim Brown wrote:
> > Is there a 102nd (or in Eli's case, 80th) "margin bar" (red line)
> > in DrRacket to warn coders of the Style width of their code?
> 
> Now there is, in the git head, thanks to Robby. Preference, edit,
> general. And yes, Eli can set the width to his beloved 80.
> 
> Thank you Robby -- Matthias

+1 -- this is probably the first feature I wanted when I started using
drr around 98-99...  (I had some hack in the ancient "drswindle" thing
that did something similar but much dirtier.)


Yesterday, Tim Brown wrote:
> 
> Style seems to demand:
> 
> > Similarly, if your function or method consumers two (or more)
> > optional parameters, keyword arguments are a must.
> 
> So 5 optional parameters must have keywords. Becomes:
> [...]

This is because an all-optionals interface means that you need to know
and specify all of the defaults if you want to change the last one.
For example, if I want to spit out unmatched text from some input:

    (regexp-match #rx"foo" in 0 #f out)

I must specify `0' and `#f' even though I'm not interested in them --
I just need to get to that last input.

But your case had a completely different motivation, and it was better
to get rid of the default for different reasons too.


> >       (for/fold ((best-sacks (list sack)) (best-sack-value sack-value))
> >         ((qty (in-range 0 (add1 (min max-q-vol max-q-wgt)))))
> >         (define-values (best-sack* best-sack-value*)
> 
> The <identifier>* notation... is that Style?

In schemes (and sometimes in lisps) a `foo*' is frequently used as a
"prime" thing -- so in math (for example) you'll talk about points A
and B, and how they're related to some A' and B' -- and in Racket
you'd use `*' for the same purpose.  (A good example is `syntax-case',
`syntax-case*', and `syntax-case**'.)  It's probably going to take
decades (if any) for things like "′" to become popular.  But that's
not completely uniform, of course, and it also kind-of made itself
into a "many" indicator in some contexts.  (Like `list*', `append*',
etc.)


> For maintenance purposes, I would rather put a little eye-strain
> (with over-long identifiers) and boredom (with over-many
> identifiers) in the way of my reader than have them need to refactor
> the code to introduce longer identifier names and new bindings
> because they simply cannot digest it.

I didn't have any issues with the long names -- it's the side-effect
that they had of obscuring the simple search-for-the-set-of-best-
things-given-a-set-producing-function structure of the code.  That's
something general enough that I can imagine some future library that
makes it easier, or maybe some optimization, or just replacing the
datatypes.  All of these are orders of magnitude easier when you know
what the code is doing.


> >> I can also see the recent tendency to use `define' where possible
> >> as something that goes to this end too: prefer using the same
> >> kind of binding construct to make it easier to read code.
> 
> Is this driven by consistency of binding or stopping rightward
> drift?  The Style guide seems to state that rightward drift is the
> driver.

IMO they're both equally important, but that's as subjective as
discussing poetry...

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!


Posted on the users mailing list.