> On Oct 17, 2017, at 2:36 AM, Konrad Hinsen <konrad.hin...@fastmail.net> wrote:
>
> On 16/10/2017 23:11, Matthias Felleisen wrote:
>
>> Lisp macros are easier than Racket’s in the same way that it
>> was so much easier to write procedures in ASM than in Pascal.
>
> Having used both, I fully agree, but I also wonder if it is possible to
> restore *some* of the simplicity of Lisp macros in Racket.
>
> A major point for me is that in Lisp, I use the same language and library
> functions in macros and in plain data-munging functions. In Racket, I have to
> remember a completely different set of library functions for working with
> syntax objects. I write much fewer macros than plain functions, so every time
> I work on a macro, I end up looking up much of the basic syntax-object
> manipulators again.
>
> A related point is the extensive use of pattern matching and pattern
> variables in syntax-parse. It's not hard to see their advantages, but for
> someone who uses them twice a year, it's a cognitive burden rather than a
> helpful tool.
>
> I have played with the idea of writing an interface layer that lets me apply
> plain list manipulations to the datum layer of syntax objects. I never got
> around to work on this seriously, both because of the 24-hour-per-day limit
> that I cannot seem to get rid of, and because I expect to get stuck in some
> subtleties of the macro system as so often before.
>
> Does this idea sound doable to the Racket macro masters? It would allow
> people to trade efficiency in macro writing for a more gentle learning curve,
> as opposed to syntax-rule that offers simplicity in exchange for restrictions
> in what can be done.
It’s quite doable but I think this misses the point (and I am especially
surprised that a master of types would bring this up).
Let me record in public a couple of steps of the evolution of macro concepts
and the motivation behind these steps. This is basically an excerpt from a
proposal I recent wrote for the Racket core team.
Here is a Lisp-style macro for the well-know let form (this has basically been
the same from the 60s till now):
;; S-expression -> S-expression
;; ASSUME (A)
;; e ==
;; (let ((lhs rhs) ...) body ...)
;; PRODUCE (P)
;; ((lambda (lhs ...) body ...)
;; rhs …)
;; ASSUME:
;; (A1) lhs ... are identifiers
;; (A2) rhs ..., body ... are expressions
(define-macro (let e)
(define decl (cadr e))
(define lhs (map car decl))
(define rhs (map cadr decl))
(define body (cddr e))
;; return
`((lambda ,lhs ,@body) ,@rhs))
Notice that none of the assumptions are checked: neither A nor B nor A1 nor A2.
It is not hard to add this code but it is equally easy to see that this kind of
checking code shows up over and over again. You want __abstraction__ (eliminate
repeated code) and __type classification__ (code vs S-expressions). if you are
a Racketeer or any developer who’s breathing in the 2010s.
So here we go:
(define-syntax (let stx)
(syntax-case stx ()
[(let ((lhs rhs) ...) body ...)
#'((lambda (lhs ...) body ...) rhs …)]))
Notice that this still does not check A1 and A2. Again, you can add the rules
that catch bad patterns and whatever, and when you have all of let covered you
have like 40 or 50 lines.
So you want more abstraction:
(define-syntax (our-let stx)
(syntax-parse stx
[(let ((x:id rhs:expr) ...) body:expr ...)
#'((lambda (x ...) body ...) rhs ...)]))
As you can see every step lifts the level of language to a new level. And just
like we don’t teach kids ASM first to study bad PL design from that angle
(anymore), we don’t really want to fall back to syntax-car and syntax-cdr (even
though we could).
Does this help with why going back to MACRO ASM is possibly not the right
thing? — Matthias
--
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.
