Re: sbnf (striped BNF)

> 
> kifer@cs.sunysb.edu (Michael Kifer) writes:
> > But why is it necessary to treat a language syntax as if it were some kind
> > of data? 
> 
> Um, because data is data?    :-)

Programs can be thought of as data, but there is little you can do with
that data automatically.

> BNF is a way to talk about formats for serialing data; ASN is a way to
> talk somewhat more abstractly, without needing to specify which bits
> come first and how they get parsed apart.  Maybe it puts the line
> between semantics and syntax in a slightly different place, too, eg with
> ordering.

Exactly.  f(a->b,c->d) and f(c->d,a->b) are not the same thing. They happen
to be *logically* equivalent, which is a matter for the semantics, not syntax.
There are lots of tautologies. Where do you want draw the line?

> Anyway, no, it's not *necessary*.  I think it's a good idea, and that's
> generally the sense I've gotten from the WG as well.   Lots of people
> have expressed support for this approach.
> 
> > It is not clear what are we gaining by that, but it is clear that
> > we had trouble following through with this ambitious program.
> 
> It's clear that we've had lots of trouble following through with our
> charter.  There are many, many possible reasons for that.  I suggested
> SBNF last week as a way to back off a bit from the top-down ASN-centric
> approach, to let us think more in BNF terms, but so far it hasn't been
> received like that.

Why do you think that this move has not been well-received? For instance, I
did not respond, but I always thought that BNF is the way to
go. Introducing new notation and doing research on it as we go does not
look like what we should be doing.

> In any case, I think I'd want machine-readable data in each dialect
> definition which told my software which collections were ordered and
> which were unordered.

f(a->b,c->d) is not a collection. It is a term. Do you also want to be able
to express in the syntax that p/\q == q/\p?
What about p/\(q\/r) == p/\q \/ p/\r?

It beats me why do you want to capture some part of the semantics in the
definition of the syntax.


	--michael  

> I haven't tried very hard to make the case for
> why I want that.  Process wise, I consider it an open issue.   It
> doesn't seem particular hard to provide.
> 
>       -- Sandro
> 
>

Received on Thursday, 6 September 2007 03:11:21 UTC