[stringtemplate-interest] fixed if-condition thing

[Zenaan Harkness]

On Wed, Jul 08, 2009 at 06:29:58PM +1000, Zenaan Harkness wrote:
> On Tue, Jul 07, 2009 at 11:49:04AM -0700, Terence Parr wrote:
> > On Jul 3, 2009, at 7:40 AM, Zenaan Harkness wrote:
...
> >> BTW, for next version of ST (after STBook v1), is there a chance an ST
> >> spec might be in the works, ala YAML spec (I assume JSON has one too)?
> >
> > I should take a look at that. I've already broached the subject of doing 
> > an ST book with the publisher. My fear is that the market is not large 
> > enough for the book to sell well. They may not go for it.
> 
> I agree. I feel that in a year's time, the landscape may be ready for an
> ST book.
...
>    -  Of course, syntax variability ($..$ vs <..>) - references to SGML
>       by way of comparison, perhaps ST syntax is subset of SGML (I think
>       pretty much everything is SGML subset)

Perhaps there could be an option for a lisp-like syntax?

We might just then be lisp... dunno, just a thought.

...
>    -  normalisation of syntax with respect to other languages, in
>       particular LISP!
> 
> For example, re normalisation with Lisp syntax, should we replace
>       ST             Lisp
>    -  first    ->    car
>    -  rest     ->    cdr
> 
> Re LISP, see  http://en.wikipedia.org/wiki/Lisp_(programming_language)

See also map (Scheme) or mapcar (Common List) as compared with ST's list
iteration/ template application:

   <attribute:(expr)(argument-list)>
   <attribute:t1(argument-list): ... :tN(argument-list)> 

   (mapcar #'+ '(1 2 3 4 5) '(10 20 30 40 50))


"A wide variety of programming paradigms, including imperative,
functional, and message passing styles, find convenient expression in
Scheme."


Namespace Optimization:
Here are some points emphasizing the benefits of simplifying/
regularizing syntax. Lisp is so powerful for a few reasons, primary of
which are that syntax is so regular (function calls, data, structure,
code, are all represented as simple lists), and that code and data use
the same syntax and are stored and processed in the same way as each
other; lisp thereby provides a very powerful way to do meta-programming,
or template programming. And ST, is a template type language.

It may be politically incorrect to refer to reiserfs, however the
concept of maximizing the interactions by reducing the namespaces (eg
syntax), is a foundation principle which is useful to our discussion of
ST and its specification and implementations.

ST has a relatively strict MVC separation; can we emphasize and augment
this further with namespace and syntax minimization/ regularization?:

http://web.archive.org/web/20070927003401/http://www.namesys.com/whitepaper.html
   "The utility of an operating system is more proportional to the
   number of connections possible between its components than it is to
   the number of those components. Namespace fragmentation is the most
   important determinant of that number of possible connections between
   OS components."

The point that Reiser was bringing out with respect to filesystem
semantics/ namespaces, was that we (in Unix) started with files and
directories (and even attempted (problematically) to represent
directories as files), ie just 2 namespaces, but then went and added
permission attributes, owner and group attributes, and later other types
of attributes (eg ACLs), each their _own_ namespace!
   -  Change a file?          touch, rm
   -  Change a directory?     mkdir, rmdir (different to file cmds)
   -  Change owner/ group?    chgroup, chown (same for files/dirs)
   -  Change permissions?     chmod (same for files and dir, good)
   -  Change acls?            Pretty sure it's not vi/ emacs.

As we can see, different commands needed for different entity types. We
don't have unified namespaces, and so our (unix command) syntax is
unnecessarily complex.


http://web.archive.org/web/20070927003321/www.namesys.com/v4/v4.html
   "The expressive power of an information system is proportional not to
   the number of objects that get implemented for it, but instead is
   proportional to the number of possible effective interactions between
   objects in it. (Reiser's Law Of Information Economics)

   This is similar to Adam Smith's observation that the wealth of nations
   is determined not by the number of their inhabitants, but by how well
   connected they are to each other. He traced the development of
   civilization throughout history, and found a consistent correlation
   between connectivity via roads and waterways, and wealth. He also found
   a correlation between specialization and wealth, and suggested that
   greater trade connectivity makes greater specialization economically
   viable.

   You can think of namespaces as forming the roads and waterways that
   connect the components of an operating system. The cost of these
   connecting namespaces is influenced by the number of interfaces that
   they must know how to connect to. That cost is, if they are not clever
   to avoid it, N times N, where N is the number of interfaces, since they
   must write code that knows how to connect every kind to every kind.

   One very important way to reduce the cost of fully connective namespaces
   is to teach all the objects how to use the same interface, so that the
   namespace can connect them without adding any code to the namespace.
   Very commonly, objects with different interfaces are segregated into
   different namespaces.

   If you have two namespaces, one with N objects, and another with M
   objects, the expressive power of the objects they connect is
   proportional to (N times N) plus (M times M), which is less than (N plus
   M) times (N plus M). Try it on a calculator for some arbitrary N and M.
   Usually the cost of inventing the namespaces is much less than the cost
   of the users creating all the objects. This is what makes namespaces so
   exciting to work with: you can have an enormous impact on the
   productivity of the whole system just by being a bit fanatical in
   insisting on simplicity and consistency in a few areas.

   Please remember this analysis later when we describe why we implement
   everything to support a "file" or "directory" interface, and why we
   aren't eager to support objects with unnecessarily different
   namespaces/interfaces --- such as "attributes" that cannot interact with
   files in all the same ways that files can interact with files.
   "

-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.