[lkml]   [2001]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox <>:
> Do you really believe anyone would be dumb enough to delete them out of spite
> or to further your political machinations if they could both handle the same
> configuration language.

That's a big "if" which I don't think is ever going to happen. The
CML1 and CML2 languages are nowhere near semantically equivalent. I
know them both intimately, and bridging the gap is a much harder
problem than you seem prepared to realize.

They look closer together than they are, because you can superficially
map individual features between them (CML2 derivations look like CML1
defines, for example). The big difference is subtler, and has to do with
the difference between a control language and a constraint language. As
a result, there are things you can easily do in CML2 that you can't
practically speaking do in CML1.

For CML1 and CML2 to handle the same language, we would either have
to live with the CML1 language's limitations or retrofit the old tools
to speak CML2 language. The chance of the latter happening is, I think
we can agree, effectively zero.

I know you've talked about parsing CML1 into constraints with
backtracking. Maybe you're smart enough to do that. I'm not. I
tried that route early on. I predict that if you do, you'll
experience a great deal of suffering, acquire a valuable education,
and get no good result.
<a href="">Eric S. Raymond</a>

The common argument that crime is caused by poverty is a kind of
slander on the poor.
-- H. L. Mencken
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.111 / U:2.712 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site