+1 On Tue, Apr 6, 2010 at 12:12 PM, Carl Eastlund <[email protected]> wrote: > Can we inspect all ! names in our base and consider deleting the ! part? > Can we inspect all % names in our base and consider deleting the % part? > Can we... yeah, yeah. My point is, naming conventions can be > important, let's not abandon them lightly. > > I like being able to read something and know whether it is (a) a > definition form and (b) introducing new bindings into the current > scope. If we changed, for instance, define-signature to simply > signature, there would be nothing to indicate to a user of both units > and classes that signature is a definition, whereas interface is > merely a value constructor, despite the two otherwise performing very > similar roles. > > My vote is against (struct posn [x y]) as a definition form. > > Carl Eastlund > > On Tue, Apr 6, 2010 at 2:00 PM, Matthias Felleisen <[email protected]> > wrote: >> >> Can we inspect all define- names in our base and consider deleting the >> define- part? Thanks -- Matthias >> >> On Apr 6, 2010, at 12:04 PM, Robby Findler wrote: >> >>> On Mon, Apr 5, 2010 at 1:25 PM, Matthew Flatt <[email protected]> wrote: >>>> >>>> So, I'm starting to think that we should leave `define-struct' alone >>>> (for backward compatibility) and use a different name for structure >>>> types in Racket... >>> >>> I'm definitely in favor of that, since we go back to the >>> trivial-to-port and can have lots of "#lang racket" files in the >>> distribution from the get-go. >>> >>> How about we just drop the word 'define' from 'define-struct'? >>> >>> We could do something like this: >>> >>> (struct id maybe-super-id (field ...) option ...) >>> >>> maybe-super-id = >>> | super-id >>> >>> where it generally looks like define-struct does now but without the >>> extra parens in the super case, and it binds the same things that >>> define-struct does now, except that 'id' becomes the maker instead of >>> 'make-id'? >>> >>> Given a different name, we have the opportunity to go with a more >>> radically different syntax (things like what were proposed here with >>> function arguments in the place where "(field ...)" above) but I'm not >>> sure that we should be spending our energy on that right now. Instead, >>> how about we just make sure we aren't precluding that extension in >>> this form and put it off until some time after Racket is officially >>> released? >>> >>> Robby > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev >
-- Jay McCarthy <[email protected]> Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
