Re: How can I differentiate between a here string and a "" string?

I believe the reader discards that information currently. You could
try using read tables to recover it or suggest a patch to read to not
discard it, I suppose.

Good luck and I hope life continues to surprise. ;P

Robby

On Wed, Apr 20, 2016 at 7:46 AM, Tim Brown <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]>
>>> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>>>                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 <[email protected]>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>                 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
For more options, visit https://groups.google.com/d/optout.