[Haskell-cafe] A Procedural-Functional Language (WIP)

[Rik Howard]

Hello Jo

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.)

It is a programme for designing a programming language.
>

>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.

It is leaving out a number of central issues: How to approach modularity


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.

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.


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.

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.


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?

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).


No, I'm not, it sounds fascinating.  Thank you for subsequently providing
references.

> For IO, ... variable parameters.

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.


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.

>... the 'try' built-in being analogous to 'if'.

What is the analogy?  That stuff is evaluated only on a by-need basis?
> That's already there in Haskell.


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.

Right now I fail to see what's new&better in this.


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.

I hope that this goes some way towards being an adequate response.  Once
again, thank you for your invaluable feedback -- much appreciated!

R




On 24 October 2016 at 07:22, Rik Howard <rik at dcs.bbk.ac.uk> wrote:

> Thanks, I will.
>
> R
>
>
> On 23 October 2016 at 23:23, KC <kc1956 at gmail.com> wrote:
>
>> You may want to look at
>>
>> Call-By-Push-Value
>> A Functional/Imperative Synthesis
>> By Springer
>>
>> --
>> --
>>
>> Sent from an expensive device which will be obsolete in a few months! :D
>>
>> Casey
>>
>>
>> On Oct 22, 2016 5:19 AM, "Rik Howard" <rik at dcs.bbk.ac.uk> wrote:
>>
>>> Dear Haskell Cafe Subscribers
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> http://www.dcs.bbk.ac.uk/~rik/gallery/work-in-progress/document.pdf
>>>
>>>
>>> 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.
>>>
>>> Yours sincerely
>>> Rik Howard
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20161025/6bc1b228/attachment.html>