Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 158, Issue 29

27 Oct 2016

      Richard

thanks for your response and the references which I'll look into, the
Dijkstra sounds particularly relevant.  "Procedural-functional" is not
novel; and as you also mentioned, Haskell, Clean and Mercury would qualify,
if you chose to look at it that way, as would other languages.  Any novelty
in the note would only ever be in the way that the mix is provided.  You
raise salient points about the sort of challenges that languages will need
to confront although a search has left me still unsure about PGPUs.  Can I
ask you to say a bit more about programming styles: what Java can't do,
what others can do, how that scales?

Regards
Rik

On 27 October 2016 at 13:00,  wrote:
...
Send Haskell-Cafe mailing list submissions to
        haskell-cafe@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
or, via email, send a message with subject or body 'help' to
        haskell-cafe-request@haskell.org
You can reach the person managing the list at
        haskell-cafe-owner@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Haskell-Cafe digest..."
Today's Topics:
1. Re: A Procedural-Functional Language (WIP) (Rik Howard)
   2. Re: A Procedural-Functional Language (WIP) (Rik Howard)
   3. Re: A Procedural-Functional Language (WIP) (Richard A. O'Keefe)
   4. Proof of concept of explanations for instance     resolution
      (Michael Sloan)
   5. Re: A Procedural-Functional Language (WIP) (Joachim Durchholz)
   6. Re: Proof of concept of explanations for instance resolution
      (Tom Ellis)
   7. Fwd: How to best display type variables with the  same name
      (Christopher Done)
   8. CoALP-Ty'16: Call for Participation (František Farka)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Oct 2016 16:48:47 +0100
From: Rik Howard 
To: Joachim Durchholz 
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] A Procedural-Functional Language (WIP)
Message-ID:

Content-Type: text/plain; charset="utf-8"
Jo
...
Question is not whether these things are precluded, question is how you
want to tackle them. It's not even stating design goals here.
The section on Types has been amended to note that these questions form a
part of the ongoing work.
...
The salient point of this and some other features is that they make it
...
easier to reason about a given program's properties, at the expense of
making programming harder.
You put that point well.
...
The basic concept of subtypes is simple, but establishing a definition of
"subtype" that is both useful and sound is far from trivial.
I hope that there is nothing that I've said that could be interpreted as me
thinking otherwise.  As you mentioned elsewhere, though, they look too
appealing to ignore.
...
For example. mutable circles and mutable ellipses are not in a subtype
relationship to each other if there is an updating "scale" operation with
an x and y scaling factor (you cannot guarantee that a scaled circle
stays
...
circular).
The design space for dealing with this is far from fully explored.
I'm not sure that the language could support mutable structures but I take
your point that there are complications.
...
Also, subtypes and binary operators do not really mix; google for
"parallel type hierarchy". (The core of the problem is that if you make
Byte a subtype of Word, declaring the (+) operator in Word as Word ->
Word
...
will preclude Byte from being a subtype because you want a covariant
signature in Byte but that violates subtyping rules for functions. So you
need parametric polymorphism, but now you cannot use the simple methods
for
subtyping anymore.)
Clearly there is more to be done in this area.
...
The key point to mention is that you want to maintain referential
integrity.
The document now mentions this.
...
Sounds pretty much like the conseqences of having the IO monad in
Haskell.
...
That seems fair to me although the broader impact on an entire program
would be different I think.
...
I think you should elaborate similarities and differences with how
Haskell
...
does IO, that's a well-known standard it is going to make the paper
easier
to read. Same goes for Clean&Mercury.
Something like that is addressed in Related Work.  Clean is already on the
list but it sounds, from your comments and those of others, as if Mercury
may be worth including as well.
...
It's hard to tell whether it is actually new, too many details are
missing.
Certainly you have spotted the vagueness in the types however I think that
that issue can be momentarily set aside from the point of view of novelty.
The language is purely functional with respect to functions and provides
out-vars as the only mechanism for dealing with IO.  Let's assume for the
moment that that all hangs together: if there is another language that does
that, no novelty; otherwise, there is novelty.
Once again, your feedback has been useful and stimulating.  Many thanks!
Regards
Rik