At Tue, 6 Apr 2010 14:12:35 -0400, Carl Eastlund 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.
Your point could also be that conventions are merely guidelines, and not hard rules. We definitely don't put `!' on the end of every function or method name that modifies state. > 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. Along the lines of my other message, I agree that we shouldn't change `define-signature'. It binds the name that appears right after the `define-signature', so the `define-' is a strong and appropriate signal. But `require' and `open-package' also bind in the enclosing scope. So do `init' and `field'. I expect that there are more examples. Meanwhile, local-binding forms are considerably more varied: `let', `syntax-case', `match', etc. I think `struct' is prominent enough that it will stand out, if we go with it, much as `require' does. > My vote is against (struct posn [x y]) as a definition form. Fair enough, and it may come down to a vote. I'm currently in favor of Robby's proposal. In any case, the only suggests we have so far are the ones from Robby (`struct') and Eli (just `define'). _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
