[racket] syntax, differently

Not as long as "." is legal in the middle of an identifier:

> (define a.b 3)
> a.b
3

On Wed, Aug 18, 2010 at 12:09 PM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> Nice idea. I second that.
>
>
> On Aug 18, 2010, at 11:14 AM, Jay McCarthy wrote:
>
>> This is a price you are already paying in Typed Racket. I'd like to see more ways of putting types to work implemented.
>>
>> Jay
>>
>> Sent from my iPhone
>>
>> On Aug 18, 2010, at 8:52 AM, Matthias Felleisen <matthias at ccs.neu.edu> wrote:
>>
>>>
>>> Eduardo is providing a macro that helps you abbreviate complex
>>> selector and mutator chains. The BENFIT you get is that instead
>>> of writing
>>>
>>> (posn-x (bird-posn (sky-bird (world-sky some-world))))
>>>
>>> you can write -- in Racket --
>>>
>>> some-world.sky.bird.posn.x
>>>
>>> and make Racket programs look as short as C program selectors
>>> or Java dots or Javascript dots etc.
>>>
>>> The PRICE you pay is that you annotate variables and fields
>>> with struct information. That is, you have to say somewhere that
>>> some-world is a variable that always stands for a world struct.
>>> And the sky field in world has to come with information that it
>>> always is a sky-struct. And so on.
>>>
>>> ;; ---
>>>
>>> To make this available in Racket, you'd have to port his macros
>>> from R6RS Scheme to Racket. I suspect that this would be a minor
>>> task.
>>>
>>> ;; ---
>>>
>>> To make this available in the teaching languages, you'd have to
>>> export these macros in a way that makes sense for students. Or
>>> you keep it all private to yourself.
>>>
>>> ;; ---
>>>
>>> I assume that you understand the differences between the various
>>> operations.  In Java,
>>>
>>> pos.draw
>>>
>>> comes with static knowledge about pos (an object of a certain type)
>>> and draw (a field of a certain type) that is exploited to make the
>>> notation short and safe. It isn't complete safe because of NULL,
>>> which doesn't exist in Racket or the teaching languages, but let's
>>> ignore that.
>>>
>>> In a language like Ruby,
>>>
>>> pos.draw
>>>
>>> just doesn't care, If pos has an draw field at run-time, good enough.
>>> Even if pos isn't a position but happens to have a draw field, just
>>> keep on computing.
>>>
>>> In Racket and the teaching languages, you are *forced* to write
>>> down what kind of struct you expect and what field you want:
>>>
>>> pos.check-it-is-a-posn-and-select-x-then
>>>
>>> This gives you safety a la Java (at run-time) and tells the reader
>>> at each site where you write down a selector expression what you
>>> expect. It's verbose but readable.
>>>
>>>
>>>
>>>
>>> On Aug 18, 2010, at 10:34 AM, Mathew Kurian wrote:
>>>
>>>>
>>>>
>>>> On Wed, Aug 18, 2010 at 2:41 AM, Eduardo Cavazos <wayo.cavazos at gmail.com> wrote:
>>>>
>>>> Mathew Kurian:
>>>>
>>>> However, in the case of universe/world teachpacks, where the use of
>>>> states is a vital component, a set of code can get very long,
>>>> especially if the program is very complex and contains multiple
>>>> structures (in some cases structures inside structures inside
>>>> structures) within the states.
>>>>
>>>> I agree with the critique of lengthy expressions involving nested records (structs).
>>>>
>>>> Here's how I deal with it:
>>>>
>>>>  http://gist.github.com/364754
>>>>
>>>> The particular solution is for R6RS but PLT has the necessary mechanisms for it.
>>>>
>>>> Ed
>>>>
>>>> Hey Ed,
>>>>
>>>> If you have spare time, can you please explain by what you meant in that github website. All I saw was a comparison between C and Scheme.
>>>>
>>>> Thank you
>>>>
>>>> Mathew K.
>>>>
>>>>
>>>> _________________________________________________
>>>> For list-related administrative tasks:
>>>> http://lists.racket-lang.org/listinfo/users
>>>
>>> _________________________________________________
>>> For list-related administrative tasks:
>>> http://lists.racket-lang.org/listinfo/users
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>