Re: [racket-users] How can I differentiate between a here string and a "" string?

[Eli Barzilay]

On Wed, Apr 20, 2016 at 8:46 AM, Tim Brown  wrote:
> 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!

There is definitely explicit intention to cover the "dumb end" too:

@list|!!!<<<===---===<<<###{
  foo
}###>>>===---===>>>!!!|

There's no requirement for a new line though since it's also intended to
live nicely in code too -- rather than the usual butchering of the
visual layout you get with here-strings.  But if it's just emails that
bug you, you can switch from the "@" character to something less
problematic (up to the pollen way of using a unicode diamond).


> 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.

The @-forms are intended to make this easier too.  Besides a syntax
property that identifies these forms you also get information about
which parts were the text (the {...} contents) and which were not (the
[...] stuff), each line ends up being its own string *and* it will have
its proper source location, and newlines will have indentation
information in case you want to depend on that too.  So if you want, for
example, the line number, then it's much easier with the @ syntax.

(All of the above works fine with nested @-forms (which will break a
line where they appear) and @-comments too; but it sounds like you
*don't* want to ever leave the string world once you get in it.)


> 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.

One of the main goals of the @ syntax was to make concrete-syntax-level
experiments easier instead of resorting to the much more complicated
problem of implementing a reader macro or your own parser.

[That last bit -- avoiding a parser -- is intended to be done by *using*
nested @-forms instead of rejecting them, so you get a mixture of
hopefully-easy-to-parse bits of text with nested expressions, so the
result is easier (in the S-expression sense) to handle than a monolithic
pile of text to parse.]

-- 
((x=>x(x))(x=>x(x)))   Eli Barzilay:
http://barzilay.org/   Maze is Life!

-- 
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.

Re: [racket-users] How can I differentiate between a here string and a "" string?

[Matthias Felleisen]

On Apr 20, 2016, at 8:46 AM, Tim Brown  wrote:

> Racket being touted as a programming language laboratory language. 

Well, syntax might be considered an afterthought for our world. And 
afterthought may mean neverthought here. 

-- 
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.

Re: [racket-users] How can I differentiate between a here string and a "" string?

[Tim Brown]

Read tables sounds fun!
(or at least worth a look)

I’ll work various options through in practice, and share my thoughts
once I’ve tried debugging my input strings etc.

But thanks for the input all!

On 20/04/16 13:52, Robby Findler wrote:
> 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  wrote:
>> [...]
>> 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.

I guess I was trolling for the ;P !


Tim

-- 
Tim Brown CEng MBCS 

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.

Re: [racket-users] How can I differentiate between a here string and a "" string?

[Robby Findler]

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  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  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) #
>>> col: 18 span: 10 (string-length 3) #
>>>
>>> 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 
>>> 
>>>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 

Re: [racket-users] How can I differentiate between a here string and a "" string?

[Tim Brown]

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  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) #
>> col: 18 span: 10 (string-length 3) #
>>
>> 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 
>> 
>>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 

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 

Re: [racket-users] How can I differentiate between a here string and a "" string?

[Alex Knauth]

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  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) #
> col: 18 span: 10 (string-length 3) #
> 
> 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 
> 
>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.

[racket-users] How can I differentiate between a here string and a "" string?

[Tim Brown]

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) #
col: 18 span: 10 (string-length 3) #

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 

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.