Re: [Gnu-arch-users] new language, arch, furth, etc.

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > On Tue, 2004-07-20 at 12:04 -0700, Tom Lord wrote:

    > > Oops... you are mistaken.  You contradict yourself.

    > I don't think so.

    > > Answer me this.... Why is _this_ an example of a language in use:
    > >        set-in-version: (upstream "address@hidden/tla--devo--1.3")
    > > but _this_ is not:
    > >        X-Upstream: address@hidden/tla--devo--1.3

    > Because as I said later in the thread, the latter already exists.

So, A is an example of a language in use because A has not been
implemented  but B is _not_ an example of a language in use because
B _has_ been implemented?


    > But we could take an even simpler route and stay with the
    > existing patch logs and do what email does - have the value
    > format simply depend on the key.

But all those rules for different header fields --- only a few of them
have been implemented!  Since the others have not yet been
implemented, using your logic, you are proposing implementing a new
language!

I agree with that conclusion, that you're describing a new language,
but my reasons are different.

Now that we agree a new language is needed, let's compare:

   WL (walters' language) has an indefinate number of types, 
   xl has a very general but finite number of types.

   In WL, every variable name is strongly typed: it can only
   hold a value of a specific type.   Xl doesn't have that 
   limit, although applications using xl can achieve the same
   effect by rejecting programs which define a variable to 
   have a value of the "wrong" type.

   In WL, not every program parsing a given header is guaranteed
   to get the same value.   Programs parsing headers will only
   get the same result if they both agree that the variables in
   question have certain specific types.

   WL lacks any kind of expression syntax.  Xl uses expressions to
   enable possibilities such as version-independent definitions
   (definitions stated as expressions to be evaluated in the context
   of a certain version rather than definitions stated as simple
   constants).   Xl provides many possible solutions to "the merge
   problem".

WL looks to me like a half-done job.   To finish the job, something
like xl is needed.


    > > What if the value of the variable isn't a constant but should be
    > > computed in some way?

    > Evil.  

Why?  That's a very glib statement.  I've demonstrated some uses
already and more will surely follow.   Why, exactly, "evil"?   Are you
suffering from a superstition?

    > The value of patch logs shouldn't change depending on external
    > variables.  I can't think of any reason to do that.  

"The value of patch logs"?   I'm not sure what that means.

    > A client can perform whatever computation they want on the data.

Why can't the data itself represent, unambiguously, a program, albeit
a very limited program (so that we can terminate in finite steps)?

What is this essential difference that you see between code and data?

-t