[racket] Expander vs Reader layer and general Macro advice

Thanks a lot for Jon's paper, that looks interesting.

It's reasonable for me to limit the alternate pair syntax to x:y style
identifiers, and given this constraint I think doing it in a regexp pass
through read-syntax provides the most bang for my buck.

Scott.


On Tue, Sep 10, 2013 at 6:09 AM, Jay McCarthy <jay.mccarthy at gmail.com>wrote:

> On Mon, Sep 9, 2013 at 2:39 PM, Scott Klarenbach <scott at pointyhat.ca>wrote:
>
>> @Jay
>>
>>  I'm not sure what you mean by "Doing a regex-match loses the original
>>> typing information"
>>
>>
>> I just meant that since I want a:"2" to parse as '(a . "2") and a:2 to
>> parse as '(a . 2), I'm having to perform a bunch of checks on the regex
>> match string to see if I can convert it to back to a number, etc.
>>  Something like your (string->identifier-symbol-string-or-number).  I was
>> thinking maybe that was misguided and the syntax object contained
>> information to help me in this regard.  Obviously if I go with the reader
>> approach I'll have to do it this way, but at #%top I thought maybe there
>> was some type hints available.
>>
>
> There is not.
>
>
>>  The complicated way would have to deal with stuff like (f 1):5
>>
>>
>> Ya, I never really thought of all the implications.  At first It seemed
>> like the Reader approach was the *less* complicated way, but now I
>> realize that the following should work:
>> ((λ (x) (add1 x)) 1):5 => (cons ((λ (x) (add1 x)) 1) 5)  => '(2 . 5)
>>
>> and so I must recursively parse backwards to see where the sexp
>> terminates.  Maybe this what Eli was getting at with letting the reader do
>> the job first and then looking though the syntax tree after.
>>
>
> And as you can see from all the emails, this is a complicated thing. In
> fact, it was the subject of Jon Rafkind's PhD:
> http://www.cs.utah.edu/~rafkind/
>
> Jay
>
>
>>
>> Scott.
>>
>> On Mon, Sep 9, 2013 at 5:49 AM, Jay McCarthy <jay.mccarthy at gmail.com>wrote:
>>
>>> You can do this a complicated way and an easy way. The complicated way
>>> would have to deal with stuff like (f 1):5 and the easy way would just work
>>> on stuff like x:1. I see "string":e as being part of the complicated way.
>>> In my mind, the complicated way would have to be done with a reader that
>>> produced some syntax that the expander dealt with the rest of. The easy way
>>> would just be a #%top macro like you have.
>>>
>>> I'm not sure what you mean by "Doing a regex-match loses the original
>>> typing information" given that there is no "typing" information in the
>>> original syntax. My guess is that you need to be more particular about the
>>> arguments to datum->syntax after you do the regexp spilt...
>>>
>>> (map (lambda (ns) (datum->syntax #'sym
>>> (string->identifier-symbol-string-or-number ns))) (regexp-split #rx":"
>>> (symbol->string (syntax->datum #'sym)))
>>>
>>> Jay
>>>
>>>
>>>
>>> On Sun, Sep 8, 2013 at 1:29 PM, Scott Klarenbach <scott at pointyhat.ca>wrote:
>>>
>>>> So in an attempt to improve my understanding of Racket Macros, I
>>>> thought I'd implement the following syntax change to Racket:  Introduce an
>>>> alternative syntax for pairs where they are delimited by ':' in addition to
>>>> ' . ', ie:
>>>>
>>>> "a":"b" => '("a" . "b")
>>>>
>>>> Seemed simple enough.  I hooked into #%top, split any identifiers on
>>>> ":" and reconstructed the syntax.  I also always quote the left match which
>>>> catches unbound identifiers ala javascript style object keys.
>>>>
>>>> But, now I want
>>>>
>>>> 1:2 => '(1 . 2)
>>>> "1":2 => '("1" . 2)
>>>>
>>>> Doing a regex-match loses the original typing information unless I
>>>> (manually?) store it before symbol->string conversion.  What's worse, I
>>>> also want:
>>>>
>>>> (define x 3)
>>>> k:x => '(k . 3)
>>>>
>>>> But my naive approach loses the binding information along with the
>>>> typing.
>>>>
>>>> My questions are:
>>>>
>>>> 1.)  Is my strategy wrong?  Should I just tell the Reader to convert
>>>> any x:y into (cons x y) and let the expander figure out the rest?  Are
>>>> there general guidelines to follow in this regard?  (Syntax => Reader,
>>>> Semantics => Expander)??
>>>>
>>>> 2.)  If I stick with macros, what tactics should I be using to avoid
>>>> the problems I have above?
>>>>
>>>> I'm sure that binding/typing information is a basic concern well
>>>> addressed by Racket.  I've dug through the bound-identifier=?<http://docs.racket-lang.org/reference/stxcmp.html#%28def._%28%28quote._~23~25kernel%29._bound-identifier~3d~3f%29%29> stuff
>>>> a bit, but my understanding is clearly lacking and before I go about
>>>> reconstructing lexical information ad-hoc I thought I'd post this as a
>>>> sanity check to point me in the right direction.
>>>>
>>>> Thanks for your help.
>>>>
>>>> --
>>>> Talk to you soon,
>>>>
>>>> Scott Klarenbach
>>>>
>>>> PointyHat Software Corp.
>>>> www.pointyhat.ca
>>>> p 604-568-4280
>>>> e scott at pointyhat.ca
>>>> 200-1575 W. Georgia
>>>> Vancouver, BC V6G2V3
>>>>
>>>> _______________________________________
>>>> To iterate is human; to recur, divine
>>>>
>>>> ____________________
>>>>   Racket Users list:
>>>>   http://lists.racket-lang.org/users
>>>>
>>>>
>>>
>>>
>>> --
>>> Jay McCarthy <jay at cs.byu.edu>
>>> Assistant Professor / Brigham Young University
>>> http://faculty.cs.byu.edu/~jay
>>>
>>> "The glory of God is Intelligence" - D&C 93
>>>
>>
>>
>>
>> --
>> Talk to you soon,
>>
>> Scott Klarenbach
>>
>> PointyHat Software Corp.
>> www.pointyhat.ca
>> p 604-568-4280
>> e scott at pointyhat.ca
>> 200-1575 W. Georgia
>> Vancouver, BC V6G2V3
>>
>> _______________________________________
>> To iterate is human; to recur, divine
>>
>
>
>
> --
> Jay McCarthy <jay at cs.byu.edu>
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
>



-- 
Talk to you soon,

Scott Klarenbach

PointyHat Software Corp.
www.pointyhat.ca
p 604-568-4280
e scott at pointyhat.ca
200-1575 W. Georgia
Vancouver, BC V6G2V3

_______________________________________
To iterate is human; to recur, divine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130910/c3dccb7a/attachment-0001.html>