[plt-dev] some Racket proposals & implementation

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