[bitc-dev] White space

[Kristopher Micinski]

On Mon, Aug 9, 2010 at 2:11 PM, Jonathan S. Shapiro <shap at eros-os.org>wrote:

>  On Mon, Aug 9, 2010 at 10:52 AM, Kristopher Micinski <
> krismicinski at gmail.com> wrote:
>
>>  On Mon, Aug 9, 2010 at 1:42 PM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
>>
>>>  That depends on what we mean by "functional". BitC is certainly not
>>> pure, and has never intended to be.
>>>
>>>
>> As long as we can keep composition I think it'll be well.
>>
>
> I think I agree. Mainly, I was reacting to the fact that many people say
> "functional" when they mean "pure, functional". My favorite irony in that is
> that the habit generally includes ML programmers, and ML is not a pure
> language!
>
>
>>
>>   Along the same lines, making the syntax close to c would mislead
>>>> people. BitC *isn't* C, and it doesn't behave like C. Mutable state is not
>>>> the prevailing paradigm...
>>>>
>>>
>>> Actually, I expect that mutable state *will* be the prevailing paradigm.
>>> One of the main reasons for *doing* BitC was first-class support for
>>> mutable state.
>>>
>>
>>  Okay, thanks for the insight as to the direction. I wasn't sure of this.
>>
>
> So the truth is that we don't know. As a matter of language design, BitC
> straddles this fence. But as a matter of library design, my strong suspicion
> is that the two idioms do not mix well for reasons of non-composability. If
> that turns out to be correct, then the user base will ultimately converge on
> one idiom or the other. I just don't know which one.
>

I thought I'd also write back a personal response to say that I hope I don't
ever come off as trying to lecture you on language design. I have a bad
habit of thinking less than I should before speaking (which I'm working on)
so mess up wording (or just thinking too quickly) when I should have thought
better.

I'll probably send a reply all to this later, but as I'm traveling don't
have a lot of time now, just wanted to make sure this point got across.

Thanks!
Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100809/898a7810/attachment.html