[bitc-dev] White space

[Jonathan S. Shapiro]

On Mon, Aug 9, 2010 at 4:28 PM, wren ng thornton <wren at freegeek.org> wrote:

> Jonathan S. Shapiro wrote:
> > 2010/8/8 Kristopher Micinski krismicinski at gmail.com
> >>  Did you mean we might later introduce currying syntax? Currying is at
> the
> >> core of functional languages, I don't think it should be removed.
> >
> > Since it isn't there now, it's not a question of removing it. And
> currying
> > is *not* at the core of functional languages; functional composition is.
> > There are many fine ways to provide that without adopting currying as the
> > syntax.
>
> Do you mean the literal sense of composing functions (ala (.) in
> Haskell), or do you mean composition of functionality more generally?
>

I meant composing functions a la (.) in Haskell. This is the main value of
the curried application syntax.


> If the former, does BitC have a special (efficient, non-allocating,...)
> way of dealing with other common combinators like 'flip', K, W, S,...?
> One of the major benefits of functional programming from a practical
> perspective is that we can define and use these combinators in order to
> clean up API integration issues.


We don't. But I have no problems with having these operations and letting
them be allocating operations. I merely want to preserve a useful and
powerful subset language in which it is possible to have fully
non-allocating programs. It seems very unlikely to me that such programs can
be written in what has become the functional style - too many functional
idioms require transient allocation, and too much of the idiom presumes that
those allocations occur on the heap. That's not a criticism of the idioms.
It's merely an attempt to explain why they don't work in allocation-free
subprograms.

Perhaps it is a failure of my imagination, but I don't see writing
high-performance kernels with a functional idiom any time soon. The
functional idiom only performs because it can be aggressively optimized. An
implication of this is that the idiom *per se* is describing something
relatively distant from the machine behavior. To the extent that this is
true, it is a failing idiom for low-level systems programs.

Or to put it another way: low-level problems are not served by abstraction;
they are served by low-level expressiveness.


shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100810/79174c13/attachment.html