[plt-dev] some Racket proposals & implementation

+1

On Tue, Apr 6, 2010 at 12:12 PM, Carl Eastlund <carl.eastlund at gmail.com> 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 <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
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

"The glory of God is Intelligence" - D&C 93