Jonathan S. Shapiro wrote:
On Fri, 2005-01-28 at 20:30 +0600, Constantine Plotnikov wrote:This mechanism is the way to define a type of closures that are fixed size, assignment compatible, and do not require memory allocation.
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?
Did not you position the language as general-purpose system programming langauge? I think that these are quite tipical tasks for such langauge. It would be good if BitC specification specified the planned applicablity of the language.implest 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.However, can you explain why facets are relevant to system libraries?
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.
If usuability issues are ignored, there will not be too much code to verify ;).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 tointroduce 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.
Let's return to the original example. We may need to export null channel and zero channel from the process.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.
If facet are used the code that is generated by capidl call facet. Facet dispatches call to appropriate method. The stream is exported by calling "CapIDL.Channel.export(streamFacet)".
If just stub functions are genrated we will need to define mechanism that will forward call to either null or zero stream depending on object id. This will be some reinvention of mechanism similar to facet.
Constantine
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
