>
>
>
>
>>
>>> 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.
>
I know this but the problem with a fixed block is not this , its the
other stuff you can do in fixed .. so you need 2 types of fixed if you
take it out of unsafe
eg fixed int32 fiveItems[5];
has a different meaning to
fixed (int* p = &fiveItems.x)
{
*p = 1;
}
and the reason they used a keyword is that you can only access that array
in a fixed unsafe block via pointers.
you cant just go myobj.fiveItems[2] , though there is no technical reason
, it just never got added you have to go
fixed (int* intPtr = myobj.fiveItems)
{
*intPtr = 12;
*intPtr[3] = 21;
*intPtr[200] = 12; //pop
}
no run length checking etc , this is different from stackalloc which does
do runlength checkng
>
>> 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.
>
Can you put it on a block {} containing the statement ? That would be
cleaner .. statements can be messy embedded in lambdas etc. Also not sure
why you cant do this on methods
funt() { xyz... internatlfunc() abc}
[COMMIT_POINT]
internatlfunc() { }
>
>
>
>>
>>> 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.
>
I knew you meant more , in C# its all blended. This is more of a
contraint people want something similar on generics..
http://stackoverflow.com/questions/13988666/c-sharp-generic-method-as-extension-with-where-clause
public T f_DeepClone<T>(T obj)
where T : (SerializableAttribute)
{
return (T) obj;
}
Thos could be done in the compiler . but what you want is this ?
public IType f_DeepClone<T>(IType obj)
where IType : (SerializableAttribute)
{
return (T) obj;
}
whatabout
[ParamConstraint ( SerializableAttribute)]
public IType f_DeepClone<T>(IType obj)
where IType : (SerializableAttribute)
{
return (T) obj;
}
this can be now at program startup via reflection and a static intializer
on the paramConstraintAttribute class. Though you could check with a post
compile tool.
> 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.
>
How is this different to C# type constructors ? Or are you trying to
create a type constructor for generic types ?
>
>
>> 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.
>
I meant part of read only requirements in list above .. which listed
const immutable etc.
>
>
>> 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.
>
F# has tails calls on the CLR.
>
>
>> 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.
>
Yep . when i write a ingle threaded message pump of something like node.js
i dont want the multi threded baggage.
>
>
>> 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.
>
1.only Object which is almost degenerate . getHashCode, dispose ,equal are
recommended to be overwritten in all implementations. in C# 1.0 strings
didnt override == and i remember some people had issues with str1 == str2
being based on objects implementation eg it compraed equality of objects by
their address.
2. Windows 8 winrt C# types that are exported must be sealed. ( they do
fake inheritance for UIElement via some 3 interface mechanism)
3. You can pass in a class which does all the work the base class of the
type , eg extention by composition not inheritance
4. People now are using tricks with generics delegates / Func and Action
to attach implementations to the interface for some methods.
That said inheritance can be faster even at a cost in maintanance since
with lots of interface you end up having lots more virt calls.
>
>
>> 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?
>
Personally i would just remove the unsafe concept .. or severely reduce it
( maybe just take an address or pointer arithmatic) the benefits of
safety are now better known . When it was introduced a lot of people came
from C ..few devs would use pointers in a C# app these days without a damn
good reason.
Maybe just remove the unsafe compile stuff but leave unsafe blocks as is.
>
>
>> 11 ref counting as an option for tracking a class.
>>
>
> Possibly. But along with this one: borrowed pointer types.
>
What about winrt style just cast to IWeakReference ? Thats already in
C# ( the Weak ref part but the ARC is done in the C++ runtime) and it does
it through the vtable , is the virtcall price too high ? Also note the api
recommends no cycles ( "they are bad design decisions most of the time")
..it doesnt detect it and if there is a cycle and the ref count will just
remove the objects which is valid in winrt since all objects inherit from
weak reference. Its valid to temporarily create a cycle but you must
handle removal ( via going to null) .
I would add 2 more things -
1. Native apps that can call C# libs via stdcall/fast call . Impossible i
know. With windows 8 you can go the Com route which is sort of ok , but
not on Linux AFAIK . if possible it would be my #1 . Maybe this can be
addressed via service like components with its own thread , message pump
and GC which is loaded into native process and you comunicate to it via
messages.
2. pinvoke improvenments
Such a C# would be very usefull especially on hand devices , games or high
performance computing. You could also get some cred as it is not just a
"java clone" like C# is seen ( though its more) it can do things java cant
get close to . Running fast on 95% of desktops and most handhelds is pretty
damn good.
Note if it worked MS may just pinch a ton of the ideas.. or just buy
the work.
Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
