Alex, Thank you for that suggestion. However, one of my motivations for using here strings is that they are inherently dumb. As long as I avoid the terminator at the end of my line, I can bosh characters into it without fear or favour. at-exp are on the other end of that dumb-smart spectrum; for example I have often been caught out when importing something with an email address within!
I expect an algorithm to determine the position of an error in a smart string (and I guess that even includes "" with its backslat escaping) to be harder than that in a dumb one. So I’m probably going to stick with a bit of arithmetic with the here string. I’m just surprised that, with Racket being touted as a programming language laboratory language, nobody has had to figure out where a syntax error lies within a string. Tim On 20/04/16 12:54, Alex Knauth wrote: > Jens Axel Soegaard's infix package does something similar. It solves part of > this problem by using at-exp for longer strings, instead of using here > strings. Because of that, it can tell the difference by using the `'scribble` > syntax property that at-exp puts there. > > I'm not sure whether a similar syntax property exists for here strings. Would > that (at least partially) solve your problem? > > The place in the source where the infix package does this is here: > https://github.com/soegaard/infix/blob/master/infix/main.rkt#L50 > > (let* ([from-at? (syntax-property stx 'scribble)] > [offset (if from-at? 0 1)] > ...) > ...) > > Based on that syntax property, it defines the `offset` identifier as either > `0` or `1`, and adds that to the `col` and `pos`. > > Although, much like your `(parse "'Hello\", said John")` example, that isn't > quite sufficient, because it shows the wrong source location for things like > this: > > #lang at-exp racket/base > (require infix) > (define x0 0) > (define v 5) > (define dt 1) > @${x@"0" + v*dt} > > The sources for the `v` and the `dt` are 3 characters behind where they > should be because the @"0" was automatically merged with the string. (Direct > string escapes are handled specially.) > > If you want more thorough source locations within strings, you probably have > to do more work than that, for all the cases of string escapes that you want > to handle. > > Infix package docs: > http://docs.racket-lang.org/infix-manual/index.html > Infix package source: > https://github.com/soegaard/infix/tree/master > >> On Apr 20, 2016, at 5:31 AM, Tim Brown <tim.br...@cityc.co.uk> wrote: >> >> Folks, >> >> I am writing a parser that will eventually take a string syntax object >> to parse. I want to report errors where they are in the source file; >> and with port-count-lines, and a bit of basic arithmetic, I should be >> able to do this trivially. Except... for simple tests I will be using >> quoted strings; but in anger, I will be using here strings. >> >> ;; --------------------------------------------------------------------- >> #lang racket >> (define-syntax (wheres-my-string stx) >> (syntax-case stx () >> [(_ s) >> (eprintf "col: ~a span: ~a (string-length ~a) ~s~%" >> (syntax-column #'s) >> (syntax-span #'s) >> (string-length (syntax-e #'s)) >> #'s) >> #'s])) >> >> >> (wheres-my-string "abc") >> >> (wheres-my-string #<<$ >> abc >> $ >> ) >> ;; --------------------------------------------------------------------- >> >> My stderr output is: >> col: 18 span: 5 (string-length 3) #<syntax:...> >> col: 18 span: 10 (string-length 3) #<syntax:...> >> >> The syntax objects, when printed in DrRacket don’t have anything more >> to distinguish an ordinary string from an inline string. >> >> Aside from (- span string-length) being 2 or >= 7, is there any better >> way to identify the here string? >> >> Thanks, >> >> Tim >> >> PS: Ow, I’ve just thought; I’ve got a similar problem with: >> >> (parse "'Hello\", said John") >> >> and its #\\ quoting. Does anyone have any ideas about this >> >> -- >> Tim Brown CEng MBCS <tim.br...@cityc.co.uk> >> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ >> City Computing Limited · www.cityc.co.uk >> City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB >> T:+44 20 8770 2110 · F:+44 20 8770 2130 >> ──────────────────────────────────────────────────────────────────────── >> City Computing Limited registered in London No:1767817. >> Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE >> VAT No: GB 918 4680 96 > > -- Tim Brown CEng MBCS <tim.br...@cityc.co.uk> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ City Computing Limited · www.cityc.co.uk City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB T:+44 20 8770 2110 · F:+44 20 8770 2130 ──────────────────────────────────────────────────────────────────────── City Computing Limited registered in London No:1767817. Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE VAT No: GB 918 4680 96 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
