First of all, I really didn't mean any offense. I think the at-reader
and my nestable string delimiters are trying to solve slightly different
problems, and I didn't really convey that well. I didn't mean for it to
be "Eli bait". Let me explain my use case a little, and maybe my
earlier mail will seem less baiting in the context I had intended,
albeit poorly communicated.
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.
So I really do just mean that the string delimiters themselves nest --
IE it balances them so that the string doesn't necessarily end once it
hits an ending delimiter. So yes, any two characters will do for the
job. That in itself is something that I've wanted independent of
anything else, so for me that was a good enough reason to make this, and
is something that I'll use it for, to avoid things like \", which have
always irked me (whether or not it's reasonable that that should bother
me).
As for other aspects of nesting and my other uses of these strings, the
at-reader makes perfect sense if you want to nest various expressions
inside a string that needs to remain a string at run-time, such as is
done in scribble. But in my case that's not what I want for, say, #lang
rash, or other nebulous embedded language ideas I have floating around
my mind. Basically, I want to have a macro that will be fully in charge
of determining the meaning of the string, and I want to be able to use
the same reader functions in the macro that I use in the #lang. But to
use the same read-syntax function that my language uses, I need a port
to run it on. To make this port, I really just need a string with no
pre-read syntax objects inside it. So in this case I don't want the
top-level reader of whatever #lang I'm in to look in the string, I just
want the macro to be able to use read-syntax on the full string. If the
middle of the string has already been read into syntax objects, my
reader functions would be much more complicated to write (IE I'd have to
figure out how to deal with the port ending in the middle of a
parenthesised expression or something, then use a pre-read syntax
object, then jump back into reading the next section that remained a
string while conveying whatever context I was in in the last string
segment...). And the string splitting, which is as you've shown quite
helpful in many cases, would in this case simply be something that I
would have to undo, which as you point out would be a bit of a waste.
So I see the difference as being that in uses like scribble, the bold
procedure isn't trying to use a reader on its arguments, and the
at-reader needs to have split them up and turned the nested expressions
into s-expressions already for them to have their intended meaning.
Whereas the macros I want to make want to just have a string to turn
into a port. It could potentially be that my plans for these macros are
misguided, but I have liked the results I've gotten so far and feel like
it has promise.
Here is an example of the sort of thing I've been doing with it:
;; Here is my rash macro
(define-syntax (rash stx)
(syntax-parse stx
[(rash arg:str)
;; Note that since I just get one string, it is easy to turn it into a port
;; and use my read function on it.
(with-syntax ([(parg ...) (map (λ (s) (replace-context #'arg s))
(syntax->list
(rash-read-syntax* (syntax-source #'arg)
(stx-string->port
#'arg))))])
;; rash-line-parse is what the #%module-begin of rash uses around
everything.
#'(rash-line-parse parg ...))]))
;; So basically the rash macro does exactly the same thing as #lang rash,
;; but is embeddable in #lang whatever!
Is this the best way of going about it? I don't know. But it's easier
than the way I was going about it before. Something I like about this
method is that I could nest several of these macros into each other, and
each one can do the reading however it sees fit, as long as at each
level I can pass an appropriate string to the next level down. 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).
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.»)»))
I'm a little hard pressed to come up with examples I haven't thought of
remotely concretely yet, but it seems to me that it's much easier to
have these sort of #lang-embedding macros that do their own reading if
you just have a simple string. Nesting the delimiters is just
convenient for nesting syntax for a call to another such macro in the
top level string.
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)
So in my example, I would probably have something like
(foo «...(bar «...»)...»)
and foo would be responsible for reading the string that contains bar,
and the argument of bar would have to be a string in foo's language that
contains source code for bar's language (supposing bar is another one of
these language nesting macros). So that is why in this case these
nested strings seem good to me. Those bullet points of bad things about
reconstructing one string are some of the things I'm trying to avoid by
just having a plain string in the first place. They are some of the
things that frustrated me when I was trying to write these macros using
the at-reader, and I know at least one other person is patching together
strings produced by the at-reader to make a port to achieve a similar
macro.
Second, while I love the at-reader for Scribble, I think it has
several drawbacks for nesting different syntax.
Here I should have been more clear: I mean that I think it has
drawbacks for nesting syntax using the sort of macros that I am trying
to write. It's clearly great for nesting different syntax in Scribble
documents! It's probably great for other things that I'm not trying to
do right now, or maybe it's even great for a better way of doing the
things I'm doing that has thus far escaped me.
I'm really sorry if my initial mail came off as offensive or aggressive
against the at-reader, because I really think it's great. It's just
that it doesn't seem to be the tool best suited to my particular need,
and when I had had some verbal conversations with people I had mentioned
that and they didn't see why, so I wanted to include some reasoning for
why I didn't want the at-reader for this purpose. But clearly the
use-case I had in mind was not clear in my previous email. I guess I
should have given one of my examples from this mail in my original post.
Communication has never been a great strength of mine.
But yeah, if what I'm doing still seems dumb with this explanation, feel
free to let me know my method's weaknesses.
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.
