[plt-dev] some Racket proposals & implementation

From: Carl Eastlund (carl.eastlund at gmail.com)
Date: Tue Apr 6 14:12:35 EDT 2010

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 <matthias at ccs.neu.edu> 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 <mflatt at cs.utah.edu> 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

Posted on the dev mailing list.