<div dir="ltr"><div>Hello Jo</div><div><br></div><div>apologies for the delayed reply!  Thank you for your time and thoughts.  (I'd not realised that some messages come only through the digest.  And apologies generally for taking more bandwidth after I said I wouldn't -- I hadn't realised then that there were emails lacking a response; this might be tl;dr as it is a response to two.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It is a programme for designing a programming language.<br></blockquote><div><br></div><div>From about this point in the design of the language, all you can do can be defined as functions (e.g., logical negation).  So introducing a symbol for an operation becomes something between syntactic sugar and an opportunity for optimisation.  At least, that's the thought process so far.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It is leaving out a number of central issues: How to approach modularity</blockquote><div><br></div><div>The note needs to be more clear that abstraction, application and let-blocks are an extended Lambda calculus so giving higher-order functions; it is to be lazy (or normal order, at least).  A packaging system has been conceived for the language, as have some other features, some of which may bear traces of novelty, but space is tight and the variable parameters need to get treated first.  The note tends to focus on the would-be type system because that is where the presence of out-vars makes itself most apparent.</div></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">whether it should have opaque types (and why), whether there should be subtypes or not, how the type system is supposed to deal with arithmetic which has almost-compatible integer types and floating-point types.  That's just off the top of my head, I am pretty sure that there are other issues.  It is hard to discuss merits or problems at this stage, since all of these issues tend to influence each other.</blockquote></div><div><br></div><div>There are gaps in the design.  This step is to show that at least those considerations haven't been precluded in some way by the mix of features.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">One thing I have heard is that effects, subtypes and type system soundness do not mix well. Subtypes are too useful to ignore, unsound types systems are not worth the effort, so I find it a bit surprising that the paper has nothing to say  about the issue.</blockquote></div><div><br></div><div>I'm not sure what you mean by effects (may I ask you to elaborate?  Or side effects maybe?) but subtypes would appear to offer an intuitive analogy with set theory.  It would mean extra look-ups in the deciding function to check inclusion, possibly using some sort of 'narrowable' type, and that would make showing soundness that much more involved.  Are there other beyond-the-norm complications?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Are you aware how "monadic IO" became the standard in Haskell?  It was one of three competing approaches, and AFAIK one turned out to be less useful, and the other simply wasn't ready in time (so it might still be interesting to investigate).</blockquote><div><br></div><div>No, I'm not, it sounds fascinating.  Thank you for subsequently providing references.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> For IO, ... variable parameters. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What's the advantage here?  Given the obvious strong disadvantage that it forces callers into an idiom that uses updatable data structures, the advantage better be compelling.</blockquote><div><br></div><div>The out-vars are the same as other variables in terms of updating: they have to be fresh on the way in and can't be modified after coming out -- I should make that more clear -- or was that not what you meant?  The difference (I don't know that it can be called an advantage) is that IO can be done pretty much wherever-whenever but the insistence of a try-then-else for penultimate invocations forces that doing not to be unnoticed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>... the 'try' built-in being analogous to 'if'.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What is the analogy?  That stuff is evaluated only on a by-need basis? That's already there in Haskell.</blockquote><div><br></div><div>Yes.  And at the risk of labouring the point, 'if' has a true-false condition determining which expression to evaluate; 'try' has an okay-error condition for the same.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Right now I fail to see what's new&better in this.</blockquote><div><br></div><div>Some languages allow IO expressions without any further thought being paid to the matter; some provide explicit mechanisms for dealing with IO.  The language in the note takes a mid-way approach, in some sense, that I'm not familiar with from elsewhere.  Assuming that this approach isn't in a language that I should know by now, could the approach not count as new?  It may be irrelevant on some level, I suppose.</div><div><br></div><div>I hope that this goes some way towards being an adequate response.  Once again, thank you for your invaluable feedback -- much appreciated!</div><div><br></div><div>R</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 October 2016 at 07:22, Rik Howard <span dir="ltr"><<a href="mailto:rik@dcs.bbk.ac.uk" target="_blank">rik@dcs.bbk.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks, I will.<span class="HOEnZb"><font color="#888888"><div><br></div><div>R</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 23 October 2016 at 23:23, KC <span dir="ltr"><<a href="mailto:kc1956@gmail.com" target="_blank">kc1956@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">You may want to look at</p>
<p dir="ltr">Call-By-Push-Value<br>
A Functional/Imperative Synthesis<br>
By Springer </p>
<p dir="ltr">--<br>
--</p>
<p dir="ltr">Sent from an expensive device which will be obsolete in a few months! :D</p>
<p dir="ltr">Casey<br>
    </p>
<div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_4275088264710853021h5">On Oct 22, 2016 5:19 AM, "Rik Howard" <<a href="mailto:rik@dcs.bbk.ac.uk" target="_blank">rik@dcs.bbk.ac.uk</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_4275088264710853021h5"><div dir="ltr"><div>Dear Haskell Cafe Subscribers</div><div><br></div><div>on the recommendation of someone for whom I have great respect, I have just subscribed to this list, it having been suggested as being a good place for me to get feedback regarding a project that I have been working on.  I am humbled by the level of discussion and it feels to be a very bold step for me to request anybody's time for my words.</div><div><br></div><div>The linked document is a four-page work-in-progress summary: the length being stipulated, potential novelty being the other main requirement.  Given the requirements, the summary necessarily glosses over some details and is not yet, I fear, completely correct.  The conclusion is, more or less, the one at which I am aiming; the properties are, more or less, the ones that are needed.</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><a href="http://www.dcs.bbk.ac.uk/~rik/gallery/work-in-progress/document.pdf" target="_blank">http://www.dcs.bbk.ac.uk/~rik/<wbr>gallery/work-in-progress/docum<wbr>ent.pdf</a></div></blockquote><div><br></div><div>The work arises from an investigation into functional programming syntax and semantics.  The novelty seems to be there but there is too a question as to whether it is simply a gimmick.  I try to suggest that it is not but, by that stage, there have been many assumptions so it is hard to be sure whether the suggestion is valid.  If anyone has any comments, questions or suggestions, they would be gratefully received.</div><div><br></div><div>Yours sincerely</div><div>Rik Howard</div><div><br></div></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a><br>
Only members subscribed via the mailman list are allowed to post.<br></span></blockquote></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>