W3C home > Mailing lists > Public > www-svg@w3.org > December 2012

RE: Turing completeness and syntactic elegance; was Re (2): Proposal: Nesting SVG Graphics Elements

From: David Dailey <ddailey@zoominternet.net>
Date: Sat, 1 Dec 2012 08:51:23 -0500
To: "'David Woolley'" <forums@david-woolley.me.uk>, <peasthope@shaw.ca>
Cc: "'SVG List'" <www-svg@w3.org>
Message-ID: <000901cdcfca$f382ee40$da88cac0$@net>
David Woolley and Peter (peasthope) and I have been talking a bit about what
SVG is, how it got that way and how it ought to evolve. Some have always
argued for a lean clean syntax, others for power and features. The essence
and beauty of the language in my mind has always been power/elegance
(expressiveness per authorial effort). In part, that is what makes
declarative languages like HTML, SVG, and SVG/SMIL so appealing to authors.

Jon Ferraiolo's comments on how SVG got to be where it is at [1, 2] are
quite informative I think.

I would hope that the Working Group will give serious thought to our
proposal to incorporate randomness into SVG [3,4] . It is a declarative
technology that combines some of the numerical sophistication that Peter
muses about, with ease of authoring, fundamental consistency with the other
conceptual building blocks of the language and when combined with
<replicate> [5] reduces code size and complexity by orders of magnitude. It
also has intense consistency with <animate> and offers considerable
symbiosis for future development.

I haven't yet really heard a reason why not to do it since it solves so many
use cases that the WG seems, otherwise, to be inventing dozens of little
workarounds to address. Let's think more globally!


[2] http://cs.sru.edu/~ddailey/svg/open/How.svg 
[3] http://cs.sru.edu/~ddailey/svg/RandomTalk.html
[4] http://cs.sru.edu/~ddailey/serendipity.doc  
[5] http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm 
-----Original Message-----
From: David Woolley [mailto:forums@david-woolley.me.uk] 
Sent: Saturday, December 01, 2012 6:34 AM
To: peasthope@shaw.ca
Cc: SVG List
Subject: Re: Turing completeness and syntactic elegance; was Re (2):
Proposal: Nesting SVG Graphics Elements

peasthope@shaw.ca wrote:
> From:	"David Dailey" <ddailey@zoominternet.net>
> Date:	Thu, 29 Nov 2012 21:37:22 -0500
>> I think at the core of the debate is what sort of a thing we want SVG to
> A related question.  Two features of SVG and siblings are striking; 
> absence of capability for calculation and clumsiness of syntax.
 > In comparison, PostScript handles calculations nicely and syntax  > is
elegant.  So I've always wondered about a language combining the

I think you will find that it is generally only scientists and
mathematicians who distribute documents in Postscript.  Most people convert
them to PDF, which is Postscript with all the calculations and control flow
resolved out.  PDF is a lot more difficult to hand code than SVG and hand
coding of Postscript died out quite quickly (early 80s).

SVG's origins tend to be more in terms of declarative languages, whereas
Postscript is procedural.  I think there has been a lot of mission creep in
SVG, especially before Adobe bought out Flash, when my impression was that
they were trying to make it into a alternative Flash. 
Unfortunately, it is the nature of standards that they end up trying to do

The awkwardnesses in syntax probably arise from the fundamental policy
decision to use XML (whilst its origins forced the use of XML, my feeling is
that XML is much overused because it is fashionable, in areas which don't
have a vested interest in its use).  Some of it is probably the result of
mission creep.

Because it is not how arithmetic is taught in school, the RPN used by
Postscript gives a steep initial learning curve.

> capabilities of the Web markups with the syntactic elegance and Turing 
> completeness of PostScript.  I guess the question has been discussed 
> but I've never encountered a mention.
> The above is slightly provocative, only for emphasis.

David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam, that
is no longer good advice, as archive address hiding may not work.
Received on Saturday, 1 December 2012 13:52:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:30 UTC