On Mon, Jan 6, 2014 at 5:24 AM, Jonathan S. Shapiro <[email protected]>wrote:

> On Sat, Jan 4, 2014 at 9:23 PM, Ben Kloosterman <[email protected]>wrote:
>
>> Also foreach typicaly throws exceptions ( collection modified while being
>> enumerated is very useful)  , which are typically heap allocated ( they
>> possibly could be region but it gets messy fast )  .
>>
>
> Exceptions don't need to be heap allocated and should not be. That's an
> implementation or a design bug, depending on your point of view.
>

I wouldnt call it a bug . Unwinding can get messy with Exceptions on the
stack especially the usefull out of stack exception.


>
> To the extent possible, it is always better to capture mistakes at static
> compile time than at run time. A lot of the exceptions that C# FOREACH
> throws are things that can and should be type checked out.
>
> But I suspect we probably all agree about that. :-)
>

Yes dependent types etc  but collection modified while being enumerated is
not one of them and is useful  this gets exactly to my point on interfaces
being nice for business apps  but  you will want to take such exceptions
and checks out becuase you want to use it at a lower level . Thats why I
have type classes as no compromise system programming and interfaces for
higher level programming where performance is secondary to maintanability/
flexability. You dont need to compromise and you get a nice OO story cheap.

BTW for foreach , i always wanted fastforeach or unsafe foreach , with does
no bounds checks when you do the concurency yourself and its
lighter...Question with the conditional / multi threading code elimination
can we tie this to conditional keywords ?

ie when we explcitly go " nothread noheap foreach " then those conditionals
go into affect. It seems better than tying it to attributes. SInce we only
have 2-3 conditionals really. Though i supose its just sugar for attributes
( though we dont have an attribute on a keyword like foreach) . This would
eliminate the collection modified when enumerated check when not working
with concurrent code.


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

Reply via email to