On Mon, Feb 16, 2015 at 12:37 AM, Matt Oliveri <[email protected]> wrote:
> On Mon, Feb 16, 2015 at 2:22 AM, Keean Schupke <[email protected]> wrote: > > > - That this necessarily means poor performance, or that you have to > compile > > like Haskell. My project uses unboxed types with no garbage collection > and > > compiled imperative code in the IO monad directly to 'C' like code. So > > really performance is as 'C' but with a proper logical type system. > > Without going into details about your project, it's hard for me to > tell whether you're being too optimistic about your project, or your > project is a lot less like Haskell than you've been making it sound. > Or whether he's actually right. Just saying. Language design occurs on many simultaneous fronts. Some mathematical, some social, some visceral, probably others. Success isn't determined by any one of them individually. > That's the spirit! In all likelihood, you'll never convince Shap to > use monadic effects, even if you could solve all his technical > objections. That would be a huge stylistic change to BitC, which he > probably thinks would alienate systems programmers. I've also failed > to convince him to make a major stylistic change, and I'm still here. Pbbbt! Hey, I personally believe that curried application syntax is one of the ugliest syntactic abortions I've ever encountered. I've rejected it quite firmly once. But here we are considering how to reconcile it with higher arity functions *again* because there are other useful constructs that benefit from the currying idea. As to monads, I'm willing to learn, which is why I'm actually interested to pursue that in the other thread. Monads are one of those deceptively simple ideas that are hard to grasp, and I don't have enough experience with them to know which of my concerns are real and which are just artifacts of particular implementations. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
