> On Aug 10, 2018, at 1:02 PM, Eric Griffis wrote:
>
> A few months ago, I was similarly confused. Here's what I remember
> learning since then.
>
> Let's call the character-level syntax of a language concrete and any
> higher-level syntax abstract. By these definitions, a parser makes
> concrete syntax abstract, and an interpreter translates one piece of
> abstract syntax into another.
FWIW, this is an rather non-standard use of these terms.
concrete: stream of chars
lex’ed: stream of chars turned into a stream of tokens,
which are words in the vocabulary of the language
parsed: a validation that the stream of tokens obeys
the grammatical rules of the language
StreamOfTokens —> Boolean
would work but is usually shunned for a better
alterative
parsed, again: stream of tokens turned into an abstract
syntax tree (AST) whose sheer existence validates
that the grammar rules are obeyed and which is a
good representation of the program for further
processing
further processing: skipped for now
interpreted: an AST turned into a value plus a stream
of observable side-effects
In Lisp/Scheme/Racket land, parsed, again is “parse
and expand”. In Racket land specifically, the reader
creates NOT an S-expression but an AST consisting of
syntax objects and the syntax system allows you to
add “rules” to the “parse and expand” step to map one
subtree to a different one. The key is that these rules
are written in a syntax that provides the illusion of
plain concrete syntax.
— Matthias
>
> In Racket-space, I don't often see concrete and abstract syntax
> discussed together. We tend to talk exclusively about parsing concrete
> syntax "into s-expressions," or just assume s-expressions and focus on
> abstract interpretation of syntax objects by syntax transformers.
>
> I didn't truly "get" syntax transformers until I had a working
> understanding of the expander and how it affects phase-based
> execution. I like to think of expansion as term rewriting, with syntax
> transformers as rewrite rule generators. The expander recursively
> rewrites the AST at the current phase into the AST for the next phase.
> This is a fundamentally different perspective than macros as function
> templates. The paper, Macros that Work Together, does a great job
> explaining the difference.
>
> Awareness of the current phase and an ability to re-orient "up" or
> "down" quickly are now essential skills for my day-to-day macro
> programming. Intuiting which phase a piece of code inhabits got a lot
> easier once I internalized the difference between define,
> define-syntax, and define-for-syntax.
>
> When I started with the syntax/parse collection, it was all
> syntax-parse and define-syntax-class. These days, I'll start with
> define-simple-macro and increase flexibility -- first to
> define-syntax-parser, then to syntax-parse inside define-syntax
> -- as needed. I was pretty comfortable with syntax-case and
> syntax-rules to begin with, which made picking up the syntax/parse
> analogues straight forward.
>
> Eric
>
>
> On Tue, Aug 7, 2018 at 8:48 AM Alex Gian wrote:
> Simply put, I find syntax to be a brain
>
> I can do simple stuff, often by extensive study of example code, and I even
> have the odd moment of illumination, which shows me that there is more to it
> than just masochism!
>
> What I do not have is the flow, the mojo, to be able to write syntax like
> second nature, and what's more to intersperse it with normal code without
> freaking out.
>
> So I've decided to bite the bullet and dedicate some quality time to the
> subject, without constantly winging it. In the light of this, what would the
> good folk here recommend as a reasonable path on which to proceed fairly
> quickly? I am not averse to meta-anything, but sometimes I just don't see
> the elegance that is supposed to be there.
>
> One of my targets would also be to get the hang of syntax-parse. Are there
> any tutorials out there? I do not mind if they are simple. When it comes to
> syntax, so am I.
>
>
> --
> 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.
>
> --
> 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.
--
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
