[racket] Expander vs Reader layer and general Macro advice

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130910/077fbd56/attachment-0001.html>