[plt-dev] some Racket proposals & implementation

On Apr  3, Jay McCarthy wrote:
> On Sat, Apr 3, 2010 at 8:14 PM, Eli Barzilay <eli at barzilay.org> wrote:
> > On Apr  3, Sam Tobin-Hochstadt wrote:
> >> On Sat, Apr 3, 2010 at 10:01 PM, Eli Barzilay <eli at barzilay.org> wrote:
> >> >
> >> >> They are not anywhere close to easily-enough distinguishable that they
> >> >> should be the same form.  This is just asking for confusion.
> >> >
> >> > I'm talking about the one that looks like a lambda:
> >>
> >> I know.  I think these look *much* too similar:
> >>
> >> (define-struct (m x y))
> >> (define-struct m (x y))
> >>
> >> since they have *totally* different semantics.
> >
> > Unless Jay added something that I didn't see, they don't have
> > different semantics -- the only difference is in the names that get
> > bound (`m' vs `make-m').  And from a user perspective, the similarity
> > to a function definition makes it natural to expect the first form to
> > bind `m'.
> >
> > If anything, then this is what I think could be confusing (also not
> > because of different semantics):
> >
> >  (define-struct (m n) (x))
> >  (define-struct (m x))
> >
> > but even that kind of confusion can be rare -- it should be easy
> > to see what it is if there is more than one field, or with the
> > name of the struct that is usually very different from the name of
> > a field.
> 
> I don't like supporting both because it makes errors become usages
> of the other form.
> 
> If I write (define-struct (child parent)) [forgetting the field
> names], I've just made a struct named 'child' with a field 'parent'.
> 
> If I write (define-struct (struct field1) (field2)) [inserting
> another list somehow], I've just made a struct 'struct' with parent
> 'field1' and field 'field2'.
> 
> That confusion seems bad to me.

* Yes, I said that these *possible* confusions exist.  (BTW, I
  consider only the first as a potential problem; "inserting another
  list" is the same problem you with things like (+ (1) (2)).)

* I'm perfectly fine with *only* the new form and possibly a
  (require (only-in scheme/base define-struct)) for migration.  What
  I'm saying is that if this `require' is too much for migration, and
  if having both syntaxes supported by the new one is fine in terms of
  satisfying the conservative factor, then I consider having the
  double-syntax thing a fine price.

* Again, I suggested it to get the new syntax in.  (You said that
  you're idealist and you want the new features? -- So take this as a
  stronger wish to have these features.)

* But I'm also not clear on whether there are compatibility issues
  with old struct definitions -- so the above is assuming that there
  are none.  (Including if there's a way to make things fine by
  extending how the old structs are represented in a way that is not
  visible to user code.)

* Same for the memory & runtime costs.  (In particular, I don't know
  what batch compiler you were talking about...)

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