On Sat, Sep 24, 2016 at 12:46 PM, William G Hatch <will...@hatch.uno> wrote:
>
> First, nestable strings are nice for other things as well. For
> instance, since they don't escape backslashes, they are nice for
> constructing regexps, which famously explode into mountains of
> backslashes due to being inside "" strings. They are a great
> alternative to #<<HERE strings when you want something big and
> complicated for any purpose.
You could just as well replace that with "Eli bait"... Yes, the
@-syntax is addressing exactly these kind of things.
> Second, while I love the at-reader for Scribble, I think it has
> several drawbacks for nesting different syntax.
>
> • It splits up the string at newlines. Not a huge deal -- you can
> reassemble them, but it's a bit of a hassle.
There are two reasons is splits strings:
1. Doing that adds information about newlines (hence you know more about
how the expression was written), and about parts that are indentation.
2. More importantly, since you can nest @-expressions, they must
translate to separate things -- for example, in @foo{...@bar{...}...}
you can't combine the result of (bar "...") with its surrounding,
*unless*
a. You assume that all values are strings
b. You're willing to have a planeted `string-append` in the result of
reading an @-form (and this is a big problem: both confusing, and
depending on having a `string-append` in your language)
c. You're willing to take the big GC hit of representing values using
strings only (which is almost always there, except maybe when you
use an all-literal string)
> • It expands inner @-exps unless you use |{}|. Again, not a huge deal
> as long as you sprinkle in some pipes.
Yes it does! And that's a *very* important feature.
I'm guessing that if you read "|{...}|" as some "⟦...⟧" then you get the
same thing. Only instead of choosing from a bunch of parens I wanted to
make it possible (and easy) to always find a new delimiter.
> • It removes leading white space on every line. This is a bad thing if
> your nested language is whitespace sensitive, like a python or
> haskell-style syntax would be. By reading the location data on the
> strings you get back, you can probably still reconstruct the
> original string, but it's still a hassle.
Again, this is a very intentional design that should work well in almost
all cases, including (and especially!) producing code for some
indentation sensitive language like python.
The thing is that without this feature, you cannot create code easily
unless you're creating the whole global code, maybe analogous to how
macros are much more convenient since they're local, and not global
source transformers. For example, say that you want to write this
helper in your python-generating code:
(define (generate-foo^2 expr)
@list{foo = @expr
return foo*foo})
If @-forms wouldn't have ignored indentation, you'd need a whole bunch
of complications around this:
- Can't just use @expr without adjusting it in case it has newlines
- Can't use the resulting string without adjusting its newlines to
whatever indentation is the context in which you put it in.
- And of course you need some way to deal with your own source code mess
resulting from indentation no longer being an indication of your
source structure.
(Note, BTW, that @-forms do have at least two ways to "force" including
any whitespace if that's what you *really* want.)
> • After all the at-exp's work splitting and trimming the string, every
> macro that uses at-exp output as if it were just a string has to do
> all the work of putting it all back together into a string to use as
> a port. If you just get a string in the first place, none of that
> is necessary, and the macro's interface is simpler.
I'm not sure I see what this is saying. You can't always have a string
at the macro level because there are nested *expressions*. At best,
you'll need to have a stream of characters with specials planted in it
which would provide the string representation of their values -- at
runtime. If you want to use it at the macro level, without any
expressions -- ie, just handle literal strings -- then things are very
simple: the 'scribble syntax property on newlines will have a string
holding both the newline and the indentation that follows the newline.
> So I love the at-reader, I just like nestable strings better for this
> purpose, and I want nestable strings even without syntax nesting. No
> hard feelings. If you still think these nestable strings are a bad
> idea, I'd like to hear your reasoning.
It's your use of "nestable" here that seems to me like it's making
things bogus. If you really want it to be nested, then this is exactly
what the scribble syntax is doing -- to an extreme. But if all you want
is to be able to nest the string *delimiters*, than any string delimiter
pair that is not using the same character will do... but more
importantly I don't see any cases where you would want *that* but not
the rest of the scribble syntax features.
--
((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.
