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

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