On Mon, Aug 26, 2013 at 11:44 PM, Bennie Kloosteman <[email protected]>wrote:
> > > > On Tue, Aug 27, 2013 at 1:43 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> David (I think) asked how BitC would be different from C#. On reflection, >> that's an interesting question. Given that I think BitC needs a single >> inheritance object system, it *does* start to look a bit like C#. So >> here's an attempt to answer David's question. If I were king of the >> universe, what would C# 6.0 have? >> > > It was me.. > Sorry, Bennie. I think that's the second time I've done that to you. I didn't mean to give the credit to the wrong person. I'll try to do better. > >> 1. Fixed-size arrays in the safe language subset. The fact that the * >> fixed* keyword is unsafe is just plain irredeemably stupid. I'm told >> that fixed arrays were planned for CLR 1.0, didn't make the cut, and were >> dropped. It's time. Oh. They shouldn't be limited to non-reference types >> either. >> > > well fixed allows you to draw a pointer which you can then manipulate eg > ptr + sizeof(abc) .. So you really need 2 types of fixed > > I think its a major change in C# to work with a pointer to these fixed > size embedded arrays ( as opposed to the ref type enbedded array) . They > did in v2 allow you to create such an array on the stack with stackalloc > which is surpiringly usefull . > Note usafe in C# is not that unsafe , still heaps of limitations on what > you can do its just teh GC cant handle those pointers outside of fixed. > I think we're talking past each other, and I think the confusion is that C# already has a *fixed* keyword. Yes, in C# you can write fixed int32 fiveItems[5]; The problem is that you can only do this inside an unsafe struct, and you must then pin the containing object and touch the contents of that array using an unsafe access pattern. There is absolutely no reason that this use of the "fixed" keyword should be considered unsafe. The bound is right there in front of us, and lots of compilers implement this bounds check just fine. C# should be able to do so. What's missing is the underlying support in CLR for an array whose length is part of its type. I've been told that this was planned for CLR 1.0, but was dropped at the last minute. > 2. Attributes on local variables. >> > > Weird but could be usefull. > Also on fields. One of the things you want to do with attributes is use them to encode things that cannot be encoded in the language. You can then use an external tool to check properties that you can't say in the language itself. But this is really awkward if you can't put the attribute where you need it. Come to think of it, we probably need the ability to put attributes on expressions and statements as well. I can make it work without expression attributes, but not without statement attributes. As an example of a statement attribute, consider the COMMIT_POINT() macro in Coyotos, which marks the point in the path where all locks have been acquired, failure is no longer possible, and mutations to system state can begin. We'd like to be able to annotate that point and use a tool to check that every path has exactly one such point. > >> 3. Attributes on types, not just on variables. With this, and a very >> little bit of attribute algebra, effects could be encoded as attributes and >> effect propagation could be user defined. >> > > Classes and value types can have attributes .. > Sorry. I wasn't explicit enough. I mean attributes on type *declarations*, not just type *definitions*. So for example I'd like to be able to say "this procedure takes a function as an argument, and we need the argument to be a function that has the NoGC attribute". The compiler obviously won't check that, but a tool could do so. More generally, if we can stick attributes into types in the right places, we can use the attribute mechanism to explore potential enhancements to the type system. The set of arguments that are legal on attributes also needs to expand some. All of the ones I want are statically known values. But, for example, we'd like to be able to reference type names from attributes. Of course, what I'm doing here is just a sneaky way of introducing something very similar to type constructors. > 10. Direct support for immutable types and effect-free code. >> > > part of read only . > For reasons we've discussed, immutable and read-only are very different things. readonly is not enough to get you immutable. > 2. Tail calls > Yup. But that's more a CLR issue than a C# issue. The language can't currently mandate tail calls because the CLR doesn't support it. It's a chicken and egg sort of thing. > 5. NAT type to imorve run length elimination > No no. You want Nat *kind*, not Nat *type*. But we're in agreement that we want it. Turns out you can do a *huge* number of cool things if you introduce Nat kind. > 7. Single threaded mode with compiler optomizations. > I disagree. I think what you want is a better specification of the conditions under which concurrency can occur. We're getting at the same issue, but from different points of view. > 8. First class integer SIMD support you just cant beat working on 32 > shorts at once > Perhaps. I'm not sure whether this is a core language issue or an intrinsics issue. Haven't looked at it. > ,... LINQ over SIMD arrays > No. The entire LINQ idea should have been implemented with mixfix and thunks. That would make it possible to introduce *other* sub-languages. RIght now, LINQ is a one-off hack. A very nice hack, mind you, but a hack. Why not adopt the well-established, generalized solution? > 9. Remove inheritance or add a warning . C# devs dont really use it > anymore. > Disagree. And I disagree that C# devs don't use it. Interfaces are degenerate classes, and *every single class* currently relies on inheritance for lots of different functions. > 10 Better unboxed types so you dont need unsafe ( though i dont reall > mind unsafe) , but remove the restriciton that calling a non CLR unsafe > lib is only possible with unsafe. > More generally: a clearer definition of what "unsafe" means. Why is sizeof() unsafe, just for one example? Unwise, maybe, but unsafe? > 11 ref counting as an option for tracking a class. > Possibly. But along with this one: borrowed pointer types. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
