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

[Joachim Durchholz]

Sorry for replying so late, this got stuck in the outbox.

Am 26.10.2016 um 17:48 schrieb Rik Howard:
>     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.

That's a pretty well-explored part of design space.
Unfortunately, there seems to a really hard trade-off between things 
like modularity / extensibility, freeness from surprises, and soundness, 
so most languages to not offer this.

Striking a useful compromise is hard.
Even integer arithmetic isn't easy; e.g. what's the type and value of 
(byte 254)+(byte 254)? For some languages it is (word 510), for some it 
is (word -4), some say (bigint 510). I have seen strong arguments 
brought forward for each of these answers, but since these solutions are 
mutually incompatible, and whatever answer you pick for your language, 
you have to ignore the arguments in favor of the other choices.

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

Just for reference, e.g. which of your concepts are the same in the 
other languages, which are different and what are the differences.

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

Novelty is entirely uninteresting.
Usefulness is.
Novelty *may* point out new ways to constructing something that's more 
useful than we have, but you need to point out how the novelty will help 
with that if you want to raise serious interest in your work.

Regards,
Jo