On Fri, 2005-01-28 at 20:30 +0600, Constantine Plotnikov wrote:
> Note proposed facets extension has trivial expansion to BitC code. Also 
> described approach to facets does not interfere with design of BitC too 
> much, because it uses fat pointer pattern and does not affect layout of 
> data object to be wrapped and it does not create any hidden fields.

Ignoring syntactic convenience, what do your facets provide that
closures plus constant propagations cannot accomplish just as well?

> >However, can you explain why facets are relevant to system libraries?
> >
> >  
> >
> Simplest example is a stream library stack. There are following standard 
> streams types that are likely to be use by applications: gzip, 
> encrypted, ssl, crc counting, file, HTTP input/output, BEEP input/output 
> etc. In java, it is possible to stack different stream together. In C, 
> the file stream interfaces is completely different from others. To 
> support them all a common infrastructure is needed so they will be able 
> to stack. Facets allow defining common interfaces.

Ah. I believe that we are focusing on very different problems. I have no
expectation that any of these things will be implemented in BitC in the
forseeable future, and the idioms you describe are a nightmare for
verification.

I am trying to resist the temptation to introduce language features that
will result in programs that are still harder to verify than they
already are.

> So argument is that if facets are omitted from the language, they will 
> be reinvented again and again. And it will be done poorly and in 
> incompatible ways.

>From an engineering perspective, I agree. Also, I agree that we need to
introduce a solution to this at some point. However, it isn't going to
be right now. Right now I want to stay focused on verification more
closely.

> CapIDL would benefit as there will be simpler to export different 
> implementations of the same interface using facet mechanism supported by 
> language. There would be no need to reinvent dispatcher mechanism that 
> calls different implementations depending on implementation type.

Actually, you'ld still need to reinvent the dispatcher mechanism, since
the bit-level message needs to be represented in a language-neutral
form.

shap

_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to