On Sun, Sep 25, 2016 at 4:21 PM, William G Hatch <will...@hatch.uno> wrote:
>
>> 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.
This is even more confusing. You started by saying that you *don't*
want nested expressions, just strings -- and now you don't see the
benefit of erroring on that, and furthermore:
> 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.
which means that you *do* want nested expressions after all--?
And you repeat this:
>> 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.
which makes me cringe yet again... Given all of that, you basically are
using all of the features that @-expressions have. If you could just
squint for a bit so that wherever it uses "{}"s you'd pretend it's
"«»"s, and wherever it uses "@" you'd pretend that you see a "$", you'd
see that you are going down the same path. Only you choose to keep a
bit more parens on the way.
> 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.
Right -- but those are just different ways to write string delimiters
(and "@" too) -- so continue squinting and read "|{}|" as "“”" and "|@"
as "¢", and maybe "|={}=|" and "|=@" as "⌜⌝" and "♯" etc. Same exact
idea, only (a) you're not limited to a choice from a few chosen
delimiters and instead can make up new ones, and (b) the syntax is
uniform at all levels so you (the end programmer) are not at the mercy
of the specific macro when it comes to deciding what delimiters to use.
That's, BTW, a *huge* win: uniformity at the *concrete* syntax level is
>>EXTREMELY<< important. That's the main reason sexprs are so great,
and the main problem with the wild world of tex (not latex which uses
conventions more; tex -- where any character can mean anything).
> ;; 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).
Sure it does! The "@" is implicit in the fact that
`python-ish-list-comprehend` is a macro that parses its textual body;
the "{}" are replaced by their squinted versions; and there's something
(python-ish-list-comprehend, probably) that decides that a nested
parenthesized-string following an "sqlish", which is another implicit
"@". It's all there, only implicit, which is not making your user's
lives any easier.
> As for $ in rash, I chose $ because I'm giving it *some* similarities
> to eg. bash.
Yes, I know. Read my paper: I go into much more details on quasi-
strings with some unquote characters in contrast to @-forms where "@" is
serving a double purpose which makes traditional string interpolation
*unnecessary*.
> 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.
... and then you need to face the question of what happens with
«...$blah...» given that "." is a valid character in a racket
identifier. And a bunch of other little things. (Rhetorical; No need
to reply with what you do with such things.)
> 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.
(Ha! The idea that $... behaving in different ways is *reducing*
complexity is amusing. Really.)
> 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.
The point is that "@" does the same thing at *all* level, including the
toplevel. It's *reducing* magic to an expected reader behavior. You're
nested strings -- at each level -- need some magic that *will*
eventually lead to parsing that string, leaving it implicit makes it
magical and not in a good way!
> 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.
(As a side note, I ended up going back to intense shell scripting at my
$DAY_JOB. I *know* shell scripting. I've been doing it for a while. I
know people who *know* shell scripting. There is nothing natural about
them, *especially* around anything related to $-interpolation. Quick
example: I just recently found out something new about "..${a#$b}.."
which I was confused about, partly because of how it's different between
zsh and bash. Once you find out the difference between the two, you
will not be able to use "$" and "most natural" in the same syntax.
(Shell programming should come with an achievement system: as you write
a shell script, if you get to the dreaderd '"'"' quotation of ' there
should be some happy music and you get a master quoter badge. When you
write an expression that gets your editor to mis-highlight the quoted
and unquoted parts (as done with that ${a#$b} in bash and Emacs) you get
another out-of-mainstream-quoter achievemnt.))
> 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).
Yes, I see that. I assumed that you wanted both
(rash "blah blah")
(let ([x "blah blah"]) (rash x))
to be the same, mostly because you said how much you didn't want nested
@-forms. I see what you mean now, which is, like I said, pretty much
exactly what you get with @-forms. (BTW, note how @-forms are perfect
here: since `rash` should always be used with a string input, it ends up
having a single set of delimiters instead of the two that are obviously
redundant.)
-=- -=- -=-
But I'm guessing that I lost you again, so none of this would move you.
All I can do at this point is sigh and hope that you'll end up at the
best case of re-implementing @-expressions with the slightly more
verbose syntax that you want. The worst case will be ... well, much
worse.
--
((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.
