A Procedural-Functional Language (WIP)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

A Procedural-Functional Language (WIP)

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


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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Richard Eisenberg-4
Hi Rik,

I'm unsure what to make of your proposal, as it's hard for me to glean out what you're proposing. Do you have some sample programs written in your proposed language? What is the language's grammar? What is its type system (stated in terms of inference rules)? Having these concrete descriptors of the language would be very helpful in assessing this work.

Richard

On Oct 22, 2016, at 8:18 AM, Rik Howard <[hidden email]> 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.


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.


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Joachim Durchholz
In reply to this post by Rik Howard
Am 22.10.2016 um 14:18 schrieb Rik Howard:

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

It is a programme for designing a programming language.
It is leaving out a number of central issues: How to approach
modularity, 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.

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

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.

Just my 2c.
Regards,
Jo
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Rik Howard
In reply to this post by Richard Eisenberg-4
Hi Richard

thank you for your reply.  It is becoming apparent that my explanation can be made clearer.  I'm investigating a language that takes something like core Haskell (a Lambda Calculus augmented with let blocks) to satisfy its pure function requirements but that takes a different approach when it comes to IO by employing procedures.

For IO, a procedure returns only 'okay' or an error via the mechanism that a function would use for returning values; the non-deterministic values returned by the procedure are done so with variable parameters.  For example, to define a procedure to echo once from standard in to out:

    echo = try (read string) (write string) error

The value coming from standard-in is to be captured in the 'string' out-variable and so is available to be written to standard-out, the 'try' built-in being analogous to 'if'.

Rough (inconsistent) examples exist; its grammar and type system are in a slightly better state but not yet written up properly.  What I could quickly add as an appendix, I have but the notation needs to be made more standard for easier comparison.  I am working on another paper that will address the need for a more-concrete and standard presentation.  I hope that this goes some way to answering your questions; please say if it doesn't!

Rik




On 22 October 2016 at 20:35, Richard Eisenberg <[hidden email]> wrote:
Hi Rik,

I'm unsure what to make of your proposal, as it's hard for me to glean out what you're proposing. Do you have some sample programs written in your proposed language? What is the language's grammar? What is its type system (stated in terms of inference rules)? Having these concrete descriptors of the language would be very helpful in assessing this work.

Richard

On Oct 22, 2016, at 8:18 AM, Rik Howard <[hidden email]> 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.


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.



_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Sven SAULEAU
Hi,

Seems interesting but I have difficulties to understand. Some concret example would help.

Your example could be done in Haskell using IO Monads.

Wouldn’t procedures be inlined as a compilation optimisation in Haskell ?

From my point of view your proposal will degrade code readability and wouldn’t improve efficiency of the execution.

As said earlier, I may have misunderstood. Feel free to correct me.

Regards,
Sven

On 23 Oct 2016, at 10:52, Rik Howard <[hidden email]> wrote:

Hi Richard

thank you for your reply.  It is becoming apparent that my explanation can be made clearer.  I'm investigating a language that takes something like core Haskell (a Lambda Calculus augmented with let blocks) to satisfy its pure function requirements but that takes a different approach when it comes to IO by employing procedures.

For IO, a procedure returns only 'okay' or an error via the mechanism that a function would use for returning values; the non-deterministic values returned by the procedure are done so with variable parameters.  For example, to define a procedure to echo once from standard in to out:

    echo = try (read string) (write string) error

The value coming from standard-in is to be captured in the 'string' out-variable and so is available to be written to standard-out, the 'try' built-in being analogous to 'if'.

Rough (inconsistent) examples exist; its grammar and type system are in a slightly better state but not yet written up properly.  What I could quickly add as an appendix, I have but the notation needs to be made more standard for easier comparison.  I am working on another paper that will address the need for a more-concrete and standard presentation.  I hope that this goes some way to answering your questions; please say if it doesn't!

Rik




On 22 October 2016 at 20:35, Richard Eisenberg <[hidden email]> wrote:
Hi Rik,

I'm unsure what to make of your proposal, as it's hard for me to glean out what you're proposing. Do you have some sample programs written in your proposed language? What is the language's grammar? What is its type system (stated in terms of inference rules)? Having these concrete descriptors of the language would be very helpful in assessing this work.

Richard

On Oct 22, 2016, at 8:18 AM, Rik Howard <[hidden email]> 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.


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.


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

--

Sven SAULEAU - Xtuc

 

Développeur Web

[hidden email]

06 28 69 51 44

www.xtuc.fr

https://www.linkedin.com/in/svensauleau


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Joachim Durchholz
In reply to this post by Rik Howard
Am 23.10.2016 um 10:52 schrieb Rik Howard:
> Hi Richard
>
> thank you for your reply.  It is becoming apparent that my explanation
> can be made clearer.  I'm investigating a language that takes something
> like core Haskell (a Lambda Calculus augmented with let blocks) to
> satisfy its pure function requirements but that takes a different
> approach when it comes to IO by employing procedures.

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

> For IO, a procedure returns only 'okay' or an error via the mechanism
> that a function would use for returning values; the non-deterministic
> values returned by the procedure are done so with 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.

> For example, to define a procedure to echo once from standard in to out:
>
>     echo = try (read string) (write string) error
>
> The value coming from standard-in is to be captured in the 'string'
> out-variable and so is available to be written to standard-out, 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.

> Rough (inconsistent) examples exist; its grammar and type system are in
> a slightly better state but not yet written up properly.  What I could
> quickly add as an appendix, I have but the notation needs to be made
> more standard for easier comparison.  I am working on another paper that
> will address the need for a more-concrete and standard presentation.  I
> hope that this goes some way to answering your questions; please say if
> it doesn't!

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

Regards,
Jo
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Tom Ellis
On Sun, Oct 23, 2016 at 02:14:58PM +0200, Joachim Durchholz wrote:
> 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

That's very tantalising.  Can you link to a reference?!
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Rik Howard
In reply to this post by Sven SAULEAU
Hi Sven

thanks for the response.  Some examples will definitely be produced.  The syntax in the note is one that has been stripped down to support not much more than is needed for the note.  On reflection, this does not make for a good presentation.  A suggestion has been made to use the syntax of a standard reference to make easier a conceptual evaluation of the language.  I think this could be a good way to clarify the ideas in the note; if they stand, a more-concrete (or practical) syntax could then be considered.  The example could certainly be done in Haskell and many other languages.  I'm not sure of the optimisation that you mention, so far the emphasis has been more on matters of semantics and, in the note, what effect the approach would have on a type system.  You may be right about the readability, some examples would be useful.  Coming soon!

Best
Rik


On 23 October 2016 at 12:28, Sven SAULEAU <[hidden email]> wrote:
Hi,

Seems interesting but I have difficulties to understand. Some concret example would help.

Your example could be done in Haskell using IO Monads.

Wouldn’t procedures be inlined as a compilation optimisation in Haskell ?

From my point of view your proposal will degrade code readability and wouldn’t improve efficiency of the execution.

As said earlier, I may have misunderstood. Feel free to correct me.

Regards,
Sven

On 23 Oct 2016, at 10:52, Rik Howard <[hidden email]> wrote:

Hi Richard

thank you for your reply.  It is becoming apparent that my explanation can be made clearer.  I'm investigating a language that takes something like core Haskell (a Lambda Calculus augmented with let blocks) to satisfy its pure function requirements but that takes a different approach when it comes to IO by employing procedures.

For IO, a procedure returns only 'okay' or an error via the mechanism that a function would use for returning values; the non-deterministic values returned by the procedure are done so with variable parameters.  For example, to define a procedure to echo once from standard in to out:

    echo = try (read string) (write string) error

The value coming from standard-in is to be captured in the 'string' out-variable and so is available to be written to standard-out, the 'try' built-in being analogous to 'if'.

Rough (inconsistent) examples exist; its grammar and type system are in a slightly better state but not yet written up properly.  What I could quickly add as an appendix, I have but the notation needs to be made more standard for easier comparison.  I am working on another paper that will address the need for a more-concrete and standard presentation.  I hope that this goes some way to answering your questions; please say if it doesn't!

Rik




On 22 October 2016 at 20:35, Richard Eisenberg <[hidden email]> wrote:
Hi Rik,

I'm unsure what to make of your proposal, as it's hard for me to glean out what you're proposing. Do you have some sample programs written in your proposed language? What is the language's grammar? What is its type system (stated in terms of inference rules)? Having these concrete descriptors of the language would be very helpful in assessing this work.

Richard

On Oct 22, 2016, at 8:18 AM, Rik Howard <[hidden email]> 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.


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.


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

--

Sven SAULEAU - Xtuc

 

Développeur Web

[hidden email]

06 28 69 51 44

www.xtuc.fr

https://www.linkedin.com/in/svensauleau



_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Rik Howard
All -- thanks for the feedback: it has been thought-provoking and enlightening.  There are some obvious deficiencies that can be addressed, which is probably worth doing before further discussion.  Please feel free to email me directly, otherwise I think I've taken enough space for the meantime on this valuable thread.

Best, R.




On 23 October 2016 at 22:44, Rik Howard <[hidden email]> wrote:
Hi Sven

thanks for the response.  Some examples will definitely be produced.  The syntax in the note is one that has been stripped down to support not much more than is needed for the note.  On reflection, this does not make for a good presentation.  A suggestion has been made to use the syntax of a standard reference to make easier a conceptual evaluation of the language.  I think this could be a good way to clarify the ideas in the note; if they stand, a more-concrete (or practical) syntax could then be considered.  The example could certainly be done in Haskell and many other languages.  I'm not sure of the optimisation that you mention, so far the emphasis has been more on matters of semantics and, in the note, what effect the approach would have on a type system.  You may be right about the readability, some examples would be useful.  Coming soon!

Best
Rik


On 23 October 2016 at 12:28, Sven SAULEAU <[hidden email]> wrote:
Hi,

Seems interesting but I have difficulties to understand. Some concret example would help.

Your example could be done in Haskell using IO Monads.

Wouldn’t procedures be inlined as a compilation optimisation in Haskell ?

From my point of view your proposal will degrade code readability and wouldn’t improve efficiency of the execution.

As said earlier, I may have misunderstood. Feel free to correct me.

Regards,
Sven

On 23 Oct 2016, at 10:52, Rik Howard <[hidden email]> wrote:

Hi Richard

thank you for your reply.  It is becoming apparent that my explanation can be made clearer.  I'm investigating a language that takes something like core Haskell (a Lambda Calculus augmented with let blocks) to satisfy its pure function requirements but that takes a different approach when it comes to IO by employing procedures.

For IO, a procedure returns only 'okay' or an error via the mechanism that a function would use for returning values; the non-deterministic values returned by the procedure are done so with variable parameters.  For example, to define a procedure to echo once from standard in to out:

    echo = try (read string) (write string) error

The value coming from standard-in is to be captured in the 'string' out-variable and so is available to be written to standard-out, the 'try' built-in being analogous to 'if'.

Rough (inconsistent) examples exist; its grammar and type system are in a slightly better state but not yet written up properly.  What I could quickly add as an appendix, I have but the notation needs to be made more standard for easier comparison.  I am working on another paper that will address the need for a more-concrete and standard presentation.  I hope that this goes some way to answering your questions; please say if it doesn't!

Rik




On 22 October 2016 at 20:35, Richard Eisenberg <[hidden email]> wrote:
Hi Rik,

I'm unsure what to make of your proposal, as it's hard for me to glean out what you're proposing. Do you have some sample programs written in your proposed language? What is the language's grammar? What is its type system (stated in terms of inference rules)? Having these concrete descriptors of the language would be very helpful in assessing this work.

Richard

On Oct 22, 2016, at 8:18 AM, Rik Howard <[hidden email]> 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.


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.


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

--

Sven SAULEAU - Xtuc

 

Développeur Web

[hidden email]

06 28 69 51 44

www.xtuc.fr

https://www.linkedin.com/in/svensauleau




_______________________________________________
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.
KC
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

KC
In reply to this post by Rik Howard

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" <[hidden email]> 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.


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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Joachim Durchholz
In reply to this post by Tom Ellis
Am 23.10.2016 um 22:40 schrieb Tom Ellis:
> On Sun, Oct 23, 2016 at 02:14:58PM +0200, Joachim Durchholz wrote:
>> 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
>
> That's very tantalising.  Can you link to a reference?!

I think it is in one or both of these:

Tackling the Awkward Squad
A History of Haskell: being lazy with class
A retrospective on Haskell

(It's been a decade since I last read them so they might be not exactly
what you're after, but they should be close.)
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Sven SAULEAU
In reply to this post by Rik Howard
Hi,

Ok great.

Thanks,

Regards,
Sven

On 23 Oct 2016, at 23:44, Rik Howard <[hidden email]> wrote:

Hi Sven

thanks for the response.  Some examples will definitely be produced.  The syntax in the note is one that has been stripped down to support not much more than is needed for the note.  On reflection, this does not make for a good presentation.  A suggestion has been made to use the syntax of a standard reference to make easier a conceptual evaluation of the language.  I think this could be a good way to clarify the ideas in the note; if they stand, a more-concrete (or practical) syntax could then be considered.  The example could certainly be done in Haskell and many other languages.  I'm not sure of the optimisation that you mention, so far the emphasis has been more on matters of semantics and, in the note, what effect the approach would have on a type system.  You may be right about the readability, some examples would be useful.  Coming soon!

Best
Rik


On 23 October 2016 at 12:28, Sven SAULEAU <[hidden email]> wrote:
Hi,

Seems interesting but I have difficulties to understand. Some concret example would help.

Your example could be done in Haskell using IO Monads.

Wouldn’t procedures be inlined as a compilation optimisation in Haskell ?

From my point of view your proposal will degrade code readability and wouldn’t improve efficiency of the execution.

As said earlier, I may have misunderstood. Feel free to correct me.

Regards,
Sven

On 23 Oct 2016, at 10:52, Rik Howard <[hidden email]> wrote:

Hi Richard

thank you for your reply.  It is becoming apparent that my explanation can be made clearer.  I'm investigating a language that takes something like core Haskell (a Lambda Calculus augmented with let blocks) to satisfy its pure function requirements but that takes a different approach when it comes to IO by employing procedures.

For IO, a procedure returns only 'okay' or an error via the mechanism that a function would use for returning values; the non-deterministic values returned by the procedure are done so with variable parameters.  For example, to define a procedure to echo once from standard in to out:

    echo = try (read string) (write string) error

The value coming from standard-in is to be captured in the 'string' out-variable and so is available to be written to standard-out, the 'try' built-in being analogous to 'if'.

Rough (inconsistent) examples exist; its grammar and type system are in a slightly better state but not yet written up properly.  What I could quickly add as an appendix, I have but the notation needs to be made more standard for easier comparison.  I am working on another paper that will address the need for a more-concrete and standard presentation.  I hope that this goes some way to answering your questions; please say if it doesn't!

Rik




On 22 October 2016 at 20:35, Richard Eisenberg <[hidden email]> wrote:
Hi Rik,

I'm unsure what to make of your proposal, as it's hard for me to glean out what you're proposing. Do you have some sample programs written in your proposed language? What is the language's grammar? What is its type system (stated in terms of inference rules)? Having these concrete descriptors of the language would be very helpful in assessing this work.

Richard

On Oct 22, 2016, at 8:18 AM, Rik Howard <[hidden email]> 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.


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.


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

--

Sven SAULEAU - Xtuc

 

Développeur Web

[hidden email]

06 28 69 51 44

www.xtuc.fr

https://www.linkedin.com/in/svensauleau



--

Sven SAULEAU - Xtuc

 

Développeur Web

[hidden email]

06 28 69 51 44

www.xtuc.fr

https://www.linkedin.com/in/svensauleau


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Rik Howard
In reply to this post by KC
Thanks, I will.

R


On 23 October 2016 at 23:23, KC <[hidden email]> 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" <[hidden email]> 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.


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.


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Clinton Mead
In reply to this post by Joachim Durchholz
Just curious, what was the IO approach that "wasn't ready in time"?


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

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Ronald Legere
I must admit to some curiosity about this as well.  My recollection was that the original approach was to use lazy streams 
IO:: [request] -> [respose].  

This can be managed a bit better using continuations (Perhaps continuations can also be considered a separate approach?)

And now we have the IO Monad.  (which can be defined in terms of the stream based approach but is not implemented that way)

The only other approach I am aware of is Clean's "Unique types".  
 

On Sun, Oct 23, 2016 at 11:31 PM, Clinton Mead <[hidden email]> wrote:
Just curious, what was the IO approach that "wasn't ready in time"?


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

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



--
Ron Legere ([hidden email])
 C'est le temps que tu as perdu pour ta rose qui fait ta rose si importante


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Simon  Thompson
Miranda modelled IO as a (lazy) function from [Char] -> [Char] … pretty unwieldy to use “raw”, but it was made controllable by a set of combinators that could be seen as a proto-monadic library.

Simon Y.


On 24 Oct 2016, at 15:50, Ronald Legere <[hidden email]> wrote:

I must admit to some curiosity about this as well.  My recollection was that the original approach was to use lazy streams 
IO:: [request] -> [respose].  

This can be managed a bit better using continuations (Perhaps continuations can also be considered a separate approach?)

And now we have the IO Monad.  (which can be defined in terms of the stream based approach but is not implemented that way)

The only other approach I am aware of is Clean's "Unique types".  

Simon Thompson | Professor of Logic and Computation 
School of Computing | University of Kent | Canterbury, CT2 7NF, UK
[hidden email] | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Rik Howard
In reply to this post by 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 <[hidden email]> wrote:
Thanks, I will.

R


On 23 October 2016 at 23:23, KC <[hidden email]> 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" <[hidden email]> 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.


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.



_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Richard A. O'Keefe
In reply to this post by Ronald Legere


On 25/10/16 3:50 AM, Ronald Legere wrote:
> The only other approach I am aware of is Clean's "Unique types".

That approach was also adopted in the programming language Mercury,
which includes both statically typed and moded logic programming
and statically typed functional programming, using Haskell-ish types.

It's not clear to me why Haskell, Clean, and Mercury don't already
qualify as "procedural-functional languages", especially when you
consider that the logic programming part of Mercury provides a
very clean approach to result arguments.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Joachim Durchholz
In reply to this post by Rik Howard
Am 25.10.2016 um 09:12 schrieb Rik Howard:
 >     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.

Question is not whether these things are precluded, question is how you
want to tackle them. It's not even stating design goals here.

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

Yes.

 > but subtypes would appear to offer an intuitive
 > analogy with set theory.

That's the least interesting part of subtypes, actually.
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.
(One of the major design points in designing a new programming language
is where exactly to place that trade-off, and a lot of streaks of genius
went into easing the burden on the programmer.)

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

Lots.
The basic concept of subtypes is simple, but establishing a definition
of "subtype" that is both useful and sound is far from trivial.

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.

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

 >     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

Oh, you don't have in-place updates, you have just initialization?
I missed that.

The key point to mention is that you want to maintain referential integrity.

BTW this still makes loops useless for putting values in variables,
because you can't update variables in an iteration; programmers will
still have to write recursive functions.

BTW nobody who is familiar with functional languages would consider that
a disadvantage.
Speaking of user groups: I am not sure what crowd you want to attract
with your design. It's not necessary to put that into the paper, but one
of the things that went "er, what?" in the back of my head was that I
could not infer for whom this kind of language would be useful.

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

Sounds pretty much like the conseqences of having the IO monad in Haskell.
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.

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

It's hard to tell whether it is actually new, too many details are missing.

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

You're welcome :-)

Regards
Jo
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: A Procedural-Functional Language (WIP)

Rik Howard
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




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