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
