[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

"Data blocks" syntax specification draft

On Tue, 22 May 2018 08:01:05 +0200, Christian Gollwitzer wrote:

>>> If a block of static data is large enough to start to be ugly, a
>>> common approach is to load the data from some other file, in a
>>> language which is designed around structured data.

> Thing is, you can do it already now in the script, without modifying the
> Python interpreter, by parsing a triple-quoted string. See the examples
> right here: http://pyyaml.org/wiki/PyYAMLDocumentation

Indeed. But that requires the data be parsed at runtime, and requires 
either that you use only literals, or that you use some form of string 

Imagine if the only way to write a list in Python was:

    make_list("[1, 2, 3, %d, 5]" % n)

instead of [1, 2, 3, n, 5]. That would be annoying and inefficient. 
Parsing triple-quoted strings is a second-class solution. While I don't 
think much of Mikhail's proposed solution (except as a good example of 
how *not* to design programming syntax) the motivation is interesting: 
can we come up with a good syntax for table-based data?

Many years ago, people got frustrated with having to define dicts like 

    d = {'key': value, 'a': 1, 'b': 2, ...}

and now the dict constructor allows keywords:

    d = dict(key=value, a=1, b=2, ...)

which covers the very common case of keys being strings and values being 
either identifiers or numeric literals, but cases where keys and values 
are both strings, and unlike dict displays {...} the compiler can't build 
the dict at compile-time. No compile-time optimization for us!

And I know I spend a lot of unproductive time editing tables of string 
constants, making sure all the strings are quoted, etc. I would hope 
there is a better way.

There are a very small number of languages with first-class literal 
syntax for (e.g.) XML:




and possibly a few others. But it seems to be a niche feature.

There's also table-driven programming:


an old, proven, but undervalued technique. Probably undervalued because 
it is *too simple for non-programmers to understand*.


I can't find any languages which have native data types for building 
tables. Have I missed any? Given how ubiquitous and useful tables of 
strings or numbers are, why aren't there simple ways to build such tables 
without parsing a string at runtime?

So there's a great big hole in programming languages here.