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.mccar...@gmail.com>wrote: > On Mon, Sep 9, 2013 at 2:39 PM, Scott Klarenbach <sc...@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.mccar...@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 <sc...@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 sc...@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 <j...@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 sc...@pointyhat.ca >> 200-1575 W. Georgia >> Vancouver, BC V6G2V3 >> >> _______________________________________ >> To iterate is human; to recur, divine >> > > > > -- > Jay McCarthy <j...@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 sc...@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
