* Eugene Kim <eekim@eekim.com> [010605 13:34]:
>[...]
> Here's a real-world example. CVS differences documents by lines of text.
> So if I have the source code:
>
> if (x > y) {
> doSomething();
> }
>
> and I change it to:
>
> if (x > y)
> {
> doSomething();
> }
>
> [...]
>
> I'm not sure what the answer is. Intuitively, I think that I'd like my
> version control systems to be smarter, so that if I run some code through
> lint, and I want to do a diff between a pre-lint version of a file and a
> post-lint version, I get something actually useful in return. However, at
> the same time, I don't want to ignore style completely, even if it is
> semantically redundant.
So this code is semantically the same with respect to a given compiler.
Other compilers or interpreters may differ. Python uses white space to
some degree, doesn't it?
> [...]
> I also think this is valid. But it's clearly futile to completely
> separate content from structure. So the challenge is, how granularly do
> we separate these layers?
Right. Even a carriage return can be a semantic element. In C the
comment style '//' is valid through the end of the line, yet '/* */'
does not notice carriage returns within it. A space between two words
can have meaning. Dead beat vs. deadbeat. The ordering of individual
characters even has -some semantic meaning- comprising a word otherwise
the word wouldn't mean what was intended.
The choice that Augment used is the statement. According to the Augment
Basic Skills book I have here, a statement is "headings and paragraphs
-- anything you would normally separate by two carriage returns on a
typewriter (can be up to 2000 characters long)". I would actually say
that anything where a carriage return gives additional meaning. A
statement seems something that must be displayed as a unit in order to
not lose much meaning. I encourage something more specific be devised
as an operational definition.
There's quite a bit of experience built up around statements in augment
that may indicate statements a good compromise. Perhaps this is a
decision that is arbitrary. There may be consequences to this decision.
Perhaps not every involved individual will like it for one reason or
another. Other systems may use a different decision point. It seems
clear to me that this decision will not go away and is necessary.
Other options can be chosen, but I encourage a decision be made to use
as an operating principle in development. Without a decision movement
forward is prevented.
-- -- Grant Bowman <grantbow@svpal.org>Community email addresses: Post message: unrev-II@onelist.com Subscribe: unrev-II-subscribe@onelist.com Unsubscribe: unrev-II-unsubscribe@onelist.com List owner: unrev-II-owner@onelist.com
Shortcut URL to this page: http://www.onelist.com/community/unrev-II
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2b29 : Tue Jun 05 2001 - 15:08:51 PDT