Hans Reiser wrote:

> George Beshers wrote:
>
>>
>> Ah... my language design background gets us into communication 
>> trouble :-)
>>
>> Suppose for a moment that exclude actually added functionality (as 
>> for example
>> regular expressions over file names will) what terminology would you 
>> use?
>> You see, to me the exclude is, at some level, little more than 
>> syntactic sugar
>> for the specification tools because the expressive power is 
>> equivalent in theory
>> even if using exclusion is much more convenient in practice.
>
>
> Do you consider the various turing complete languages to have 
> significant semantic differences?

Yes, but I understand your point.

The distinction I am drawing is that something is syntactic sugar if 
there is an
algorithm to translate some syntactic construct into a subset of a language
with more primitive attributes, e.g., 'elseif' is syntactic sugar.

Assume the alphabet is lower case letters for simplicity.

    exclude "bar"

becomes

    include ".|..|[ac-z][b-z][a-qs-z]|...+"

A moments thought and you will see that both can be implemented with
5 state finite state autometa (adding a failure/success state as the 5th 
state
with entire alphabet transitioning to the 5th state).

I completely agree that the exclude clause is much cleaner syntactically
and the specification compiler should handle them (requirement), but
I don't think they are a consideration in terms of the "compiled" spec
that must be evaluated in the kernel as the process is being run.

*Getting Pragmatic
*
I have been assuming a model something like the following:

 -  There is a *presentation mask* format (the mask source) that is
     platform independent and probably human readable.

 -  There is a *compiled mask* which is designed to optimize *mask
     evaluation*, i.e., the chroot like semantics.

 -  The mask evaluation is done by the *mask interpreter* which is
    in the kernel (reiser4 area until we take over the world ;-) ).

 -  That the format produced by tracing can be converted to a
    presentation mask for user editing.

Proposed definition:

    An extension to the presentation mask language is *syntactic sugar*
    Iff it does not require increasing the complexity of the mask 
interpreter.