No subject

    "Dylan is a simple dialect of Lisp with a thoroughly integrated object model..."

and

    "To those familiar with the Lisp family of languages, Dylan looks like
Scheme augmented with CLOS. However Dylan is not intended primarily for
the Lisp community. The real target audience of Dylan is application developers
now [1992] using languages such as C, C++, and Pascal who are ready to move
up to Object Oriented Dynamic Languages. Thus compatibility with other List
dialects such as Scheme and Common Lisp is not a primary goal. Dylan has been
rethought from the ground up, on a fully object oriented foundation. A primary
goal was to make the language as simple as possible, but no simpler. We have
tried to avoid multiple ways to do the same thing, to omit features that
are difficult for the average application developer to understand and use effectively,
to leave out anything that we do not know how to implement efficiently in both
space and time, and to provide a clear separation of the language executed at
run time from the development tools..."

(my [1992] annotation).
Anyway, Dylan's link to Lisp would seem pretty explicit historically, whatever the current
status (which I haven't followed... so many pretty things, so little time ;-).

ISTM that power comes from clean abstractions first, and representation syntax third.
What comes a close second to the first is that the syntax support operating on
representions as such in a way that well models the operations you are
trying to do with the corresponding abstract entities and their relationships.
The best abstractions are ones that can easily be found and assembled to reflect
the structure and dynamics of the concrete without introducing illusory aspects.

IOW, ISTM what you want to do lives in the abstract world. Representations are a necessity,
but they should not get in the way, or distort semantics or add irrelevancies. The best
representations make imagining the abstractions easy, and have transformations that
correspond to useful transformations in the abstract.

Lean domain-specific syntax makes it easier for domain specialists to focus on the essentials
when thinking about their problems, but the down side of a capability to create specialized
syntax is inappropriate use and muddying the concept space of a clean and adequate base language.

My .02 USD ;-)

Regards,
Bengt Richter