On Sun, Sep 25, 2016 at 05:10:27AM -0400, Eli Barzilay wrote:
To be clear, no offense taken
That's good. After I read "Eli bait" my mind took the rest as having
an annoyed tone, probably from reading too many online flame wars.
It's hard to tell people's emotions in text.
I think ultimately we just disagree on what features we want, but I'd
like to clarify a few misunderstandings:
Yes, and you can do all of that with just a string, which you can still
get from an @-form -- just throw a syntax error if it's not all strings.
And with just that you get the *benefit* of ignoring indentation which
makes it possible to use your syntax in a sane way.
I was doing that before, and I just didn't see that as a benefit.
Yes, and you can get the same with any string, and
(rash "stuff
in a different
language")
Yeah, if you look at the rash docs you'll see that I have examples that
do exactly that. It's kind of the point that the macro can just use any
string. All the nestable string delimiters bring to the table for these
macros is that it makes it easier to nest them without crazy escapes.
using @-forms would be a tiny delta for the implementation -- basically
just a string-append (actually, not even a delta since your macro
already allows multiple strings), and the use is more convenient:
@rash{stuff
in a different
language}
Well, my current macro doesn't allow multiple strings as you state,
but my previous macro when I was using at-expressions was exactly like
what you have there.
The only tricky bit here is that if you want to deal with only strings
and at the same time maintain a syntax-time parsing of strings, then you
need to do this whole multi-level collapsing as a macro thing, which
means no runtime expressions.
I do get runtime expressions. I'm parsing the inner strings into
syntax objects at macro expansion time, and some of those end up being
themselves macro calls, and some of them are just normal expressions
that are evaluated at runtime.
Maybe the languages have very different views on which characters do
something special (or specifically should not do something special),
including flag characters like @ (or any one you choose at the top
level or a higher level up in the nesting).
Note that the scribble syntax uses "@" by default, but it's easy to
change, as Matthew B. did with pollen.
Yes, I'm aware, but any character you choose ends up being a magic
character through each nested level unless you use |{}|, which I
didn't want.
For example, something like this could happen:
(define some-output
(rash/out
«some-query $(first
(python-ish-list-comprehend
«machine for i in machine-list where should-i-query(i)»))
$(make-query
«this is a bogus example that I'm really stretching
for, but maybe this is some nice syntax for some
sort of query producing dsl? And maybe it has some
macro in it in whatever its syntax is to
(go-a-level-deeper «in this nonsense ...»)
But importantly, no top-level reader has to know or
care what the syntax here is, nor the rash reader,
nor any reader in between, aside from simply
preserving it as a string, which I can hopefully do
in most any language.»)»))
And here you're falling into the trap I mentioned above. You're trying
to use "$" as an escape, but, for example, what happens if you want to
escape a single identifier and not an expression? Anyway, here's the
same thing using the scribble syntax:
The $ is an escape that rash has due to its design (because it
essentially quotes everything that doesn't have $), and is not
something that's generally necessary for any nested language that just
uses strings. For example:
;; starting in normal racket syntax, but with «» for convenience
(filter foo?
(python-ish-list-comprehend
«thing for x in sqlish(«select * from foo») where some_pred(x)»))
The example again is silly, but syntactically it needs neither $ nor @
nor any other magic character. The «» nesting quotes are just
convenient to avoid \" nonsense (and \\", \\\\" if there were more
nesting).
As for $ in rash, I chose $ because I'm giving it *some* similarities
to eg. bash. To escape just an identifier in rash (as opposed to a
larger expression in parens), you can use $id, which you'll see if you
look at the examples in theh rash docs. As an aside, eventually I
plan on changing it so it creates a macro that will do different
things than just escape, eg. $CAPS looks up environment variables
rather than normal variables, and maybe $«*.ext» expands globs, etc.
But my point is that the $ is a feature of the rash language that I
want, not some added complexity that I would want to avoid. So I'm
not saying I want a different @-like character for each level down,
but rather that I don't need any @-like character in the general case
(just string delimiters, either normal or preferably nestable), and
for rash in particular I want a magic character that does something
different than what the @-reader magic character does.
(define some-output
@rash/out{
some-query @(first
@python-ish-list-comprehend{
machine for i in machine-list where should-i-query(i)})
@make-query{
this is a bogus example that I'm really stretching
for, but maybe this is some nice syntax for some
sort of query producing dsl? And maybe it has some
macro in it in whatever its syntax is to
(go-a-level-deeper {in this nonsense ...})
But importantly, no top-level reader has to know or
care what the syntax here is, nor the rash reader,
nor any reader in between, aside from simply
preserving it as a string, which I can hopefully do
in most any language.}})
I think you missed one transformation:
@go-a-level-deeper{in this nonsense ...}
Note that at the superficial concrete level what this does is (a)
eliminates the need for some "$" escape character, and (b) reduces the
double-delimiter (foo «...») that you often use into a single delimiter
form of @foo{...}. This latter point is subtly important: users that
write your version need to be aware of both sexpr syntax and string
syntax and how they combine, whereas users that write my version have a
single delimiter. This is combined with the fact that "@" means the
same at all level in the scribble syntax -- that simplifies things
further by removing the need for some $-like escape construct for
interpolation. These two features make it easier to comprehend the new
thing as a new syntax rather than be aware of some places that are
texts, some that are not, and the ways to combine this all in code.
I don't see having two delimiters as a serious issue. I regularly
have lines of code that end in stuff like ))]))]]) and have no issues.
Keeping track of what's in the string (which is just normal syntax for
the nested language) seems natural and easy to me, and no more
difficult than keeping track of the difference between what is in and
out of {} delimiters. And as for a $ escape character in a shell
language syntax being confusing, I think that is maybe the most
natural shell syntax choice I've made for rash for anyone coming to it
from bash.
Note also that in *both* of these cases you need to deal with the
problem of `first` being a Racket runtime binding that gets used at the
syntax level if you want to stick with `rash/out` doing its parsing as a
macro implementation -- that's a problem that is inherently there
regardless of concrete syntax. But the scribble syntax provides an easy
way to handle this: you just need to define `rash/out` as a function (so
do the parsing at runtime), and the result plays much nicer with any
language it's used in.
No, I *definitely* want rash and rash/out to be macros. I don't want to
do any runtime parsing and evaluation for them. My current rash macro
is perfectly capable of having runtime variable references inside the
syntax that is nested in a string -- they all become syntax objects
within the context the string was in (there are examples of this in the
rash docs). So using `first` in the string isn't really different than
using `first` in a syntax template after the string is read in.
At this point I'm guessing that you'd still not be convinced. So maybe
phrase this as a challenge: see if you can come up with an actual
example where the scribble syntax won't do what you want, or examples
that you're not sure how the scribble syntax would look like. Maybe
doing this will lead to further enlightment. (Feel free to email me
such examples off-list.)
It's not that what I'm doing couldn't be done with the at-reader -- I
*was* using the at-reader to do this until recently. It was working, I
just didn't like it as much, and was frustrated with some of the details
(I had to use |{}| to not get non-strings, I had to stitch strings back
together to read them in a port, I didn't want the leading space
elimination...). I came to what I'm doing now because I like it better,
and I am personally of the opinion that it's better for what I'm doing.
I've no doubt that the @ syntax is powerful and useful (in and out of
scribble). I think we are just of two differing opinions on the matter
what features are best for the type of thing I'm doing.
I don't doubt your experience or expertise. It's just that I tried
the rash macros both with the @-reader and with just normal strings,
got it working both ways, and liked normal strings better. Nestable
string delimiters are just a little sugar on top, which I would have
made sooner or later for other purposes regardless of whether I'm
using the at-reader or not.
So I think we just have a simple disagreement as to which features are
benefits or hinderances.
Thanks,
William
--
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.
