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
|

Re: A Procedural-Functional Language (WIP)

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


Maybe not quite so clear-cut but still in the area, I think.




_______________________________________________
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
I'd like to point out that "procedural-functional" is not novel.
The programming language Euclid, an "industrial strength Pascal",
was sufficiently nailed down that a blue-and-white report from
Xerox PARC showed that it could be viewed as a pure functional
language.  And I don't know if anyone ever pointed it out, but
the language used in Dijkstra's "A Discipline of Programming",
and in a number of papers subsequently, was constrained in the
same way, to the point where that language can be seen as a
sheep in wolf's clothing too.

I'd like to point out something else.  We are looking at the
end of Moore's Law.  If that end hasn't already overtaken us,
it's visible in the rear view mirror and coming up fast.  HP,
for example, are revisiting the idea of having *LOTS* of CPUs
mixed in with the memory because conventional multicore has
its own problems.  And the Square Kilometre Array telescope's
computers are definitely going to be chock full of FPGAs as
well as more conventional things like PGPUs.

This means that in the foreseeable future we are going to need
to learn a new style of programming because the antique style,
as exemplified by say Java, just isn't going to scale.

APL was once described as "the language of the future for the
problems of the past".  I suspect that WIP may be headed in
the same direction.

Disciple http://trac.ouroborus.net/ddc/ may be of interest.
Quoting that page,
"DDC is a research compiler used to investigate program transformation
in the presence of computational effects. It compiles a family of strict
functional core languages and supports region and effect. This extra
information provides a handle on the operational behaviour of code that
isn't available in other languages. Programs can be written in either a
pure/functional or effectful/imperative style, and one of our goals is
to provide both styles coherently in the same language."

_______________________________________________
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
Am 27.10.2016 um 01:05 schrieb Richard A. O'Keefe:
> This means that in the foreseeable future we are going to need
> to learn a new style of programming because the antique style,
> as exemplified by say Java, just isn't going to scale.

I think you underestimate the adaptability of existing languages.

Java has been preparing to move towards immutability&FP. At glacier-like
speed, admittedly, but once those massively multicore systems appear,
Java will be prepared to move.

Haskell can claim to be already there, but wrt. how many issues have
been staying unaddressed, it's no better than Java, it's just different
issues.
IOW this is not a predetermined race.
_______________________________________________
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


On 27/10/16 6:17 PM, Joachim Durchholz wrote:
> Am 27.10.2016 um 01:05 schrieb Richard A. O'Keefe:
>> This means that in the foreseeable future we are going to need
>> to learn a new style of programming because the antique style,
>> as exemplified by say Java, just isn't going to scale.
>
> I think you underestimate the adaptability of existing languages.

Well, I don't think so.
>
> Java has been preparing to move towards immutability&FP. At glacier-like
> speed, admittedly, but once those massively multicore systems appear,
> Java will be prepared to move.

Nobody ever said Java (or any other language) can't ADD things.
The problem is that Java can't REMOVE the things that get in the
way without ceasing to be Java.

It's just like the way you can ADD things (complex arithmetic in C99,
threads in C11) to C, but you can't REMOVE the things that make C
horribly dangerous without it ceasing to be C (and thereby ceasing to
be useful in its admitted niche).

The fundamental operation in Java is the assignment statement.
It is fundamental to the Java Memory Model that when optimising
memory references the compiler is explicitly allowed to pretend
that threading doesn't exist.

If you fix those issues, you don't have Java any more.

> Haskell can claim to be already there, but wrt. how many issues have
> been staying unaddressed, it's no better than Java, it's just different
> issues.
> IOW this is not a predetermined race.

Nobody ever said it was.  To be honest, I don't think ANY existing
language will survive unscathed.  I really wasn't talking about a
race, simply making the point that we need new ideas, not just a
rehash of the old ones.

A very simple point:  the more cores are running at once, the
sooner your program will run into trouble, if it runs into trouble
at all.  And the more cores are running at once, the nastier it
gets for a human being trying to debug the code.  So we're looking
for a language that can give us strong guarantees that certain
kinds of mistakes either CAN'T happen because the language cannot
express them or WON'T happen because it can verify that your
particular program doesn't do those bad things.

_______________________________________________
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
Am 28.10.2016 um 02:49 schrieb Richard A. O'Keefe:
>
> Nobody ever said Java (or any other language) can't ADD things.
> The problem is that Java can't REMOVE the things that get in the
> way without ceasing to be Java.

Sure.
(Minor nitpick: Languages can change their nature by adding things, too.)

> It's just like the way you can ADD things (complex arithmetic in C99,
> threads in C11) to C, but you can't REMOVE the things that make C
> horribly dangerous without it ceasing to be C (and thereby ceasing to
> be useful in its admitted niche).

Sure, but still, it's a lot more grey area than you say - the dangerous
things in C++ are still there but the language became much less
dangerous because more modern versions come with other constructs so you
are not forced to use the horribly dangerous stuff anymore.

> The fundamental operation in Java is the assignment statement.
> It is fundamental to the Java Memory Model that when optimising
> memory references the compiler is explicitly allowed to pretend
> that threading doesn't exist.
>
> If you fix those issues, you don't have Java any more.

Value types would fix those issues without making it non-Java. There
have been multiple projects to get them into the language, so the
knowledge and interest is there, multicore is just not prevalent enough
to make Oracle recognize their relevance and putting their inclusion
high on the to-do list for the next language version.

Aliasing cannot be fixed in C++ because its constness annotations are
too weakly enforced to be useful to an optimizer.
In Java, this could be pretty different because you can't
reinterpret_cast things unless you copy them to a byte buffer before, so
the compiler does have all the guarantees.

>> Haskell can claim to be already there, but wrt. how many issues have
>> been staying unaddressed, it's no better than Java, it's just different
>> issues.
>> IOW this is not a predetermined race.
>
> Nobody ever said it was.

A certain smugness in a previous post implied something in that direction.
At least there's the idea that Haskell is in a better position than most
languages to adapt to that situation; I am sceptical, not because
Haskell is a bad language (I'd LOVE to code in Haskell) but because it
is missing some key elements to make it production-read for general use,
so it's not even going to enter the race. (Some people are happy with
that situation, which I think is pretty selfish.)

> To be honest, I don't think ANY existing
> language will survive unscathed.  I really wasn't talking about a
> race, simply making the point that we need new ideas, not just a
> rehash of the old ones.

New ideas and testbeds to see which of them hold up in practice.

> A very simple point:  the more cores are running at once, the
> sooner your program will run into trouble, if it runs into trouble
> at all.  And the more cores are running at once, the nastier it
> gets for a human being trying to debug the code.

Actually imperative languages are slowly coming to grips with that.
E.g. updatable data structures have generally fallen out of favor for
interthread communication, which has removed 90% of race conditions.

The rest is more on the level of specification problems. However, I am
not aware of Haskell helping with multithreading once IO comes into play
- does it?

 > So we're looking
> for a language that can give us strong guarantees that certain
> kinds of mistakes either CAN'T happen because the language cannot
> express them or WON'T happen because it can verify that your
> particular program doesn't do those bad things.

I do have some ideas, but not even a proof of concept so it's much too
early to talk much about that.
_______________________________________________
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
|

programming style...and type classes...

Nicholls, Mark-2
In reply to this post by Richard A. O'Keefe
im writing a msc project which touches on typeclasses (i am a relative noob at haskell, im using it in comparison to other techniques)

i believe there is advice to avoid typeclasses stylistically? (see haskell wiki on style, allegedly because it leads to creeping haskell extensions...overlapping instances etc)...which lead you into the "wild" (allegedly SPJ)

is there some sort of potted pros vs cons? its such a general question its actually hard to find something specific.

or is it simply that?
some cases overlap and some cases are undecidable, throw in functional dependency and type families and you're in a world of complexity you may not need?

vs

extensibility
?

CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.

Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.

MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

_______________________________________________
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: programming style...and type classes...

Olaf Klinke
Mark,

Haskell typeclasses are a wonderful thing to have. I dare say that typeclasses are what makes haskell code modular and re-usable, because you can develop an algorithm "aginst the class interface" and users only need to supply a class instance for their own data type in order to use your algorithm. What the wiki warns about is misuse or over-use of typeclasses. Typeclasses express properties that different types have in common, and in that respect they are somewhat similar to OO-classes. However, there is no hierarchy of inheritance.
It is true that typeclasses, particularly the more advanced ones with e.g. multiple parameters or functional dependencies, sometimes get into your way. One example is ambiguity arising from multi-parameter type classes: Suppose you have a two-parameter class

{-# LANGUAGE MultiParamTypeClasses,FunctionalDependencies #-}
class Foo a b where
  foo :: a -> b
  bar :: b -> (a,[Int])

Now you write a function using only bar:

f :: (Foo a b) => b -> Int
f = length.snd.bar

The compiler will complain that it does not know which Foo instance to use, because while bar itself mentions both class parameters a and b, snd.bar has type b -> [Int] and hence lost the information about the first class parameter. Adding a functional dependency b -> a helps in this case. But the promise that for every b there is only one a such that Foo a b holds may not be what you want. So what went wrong? Observe that

bar :: b -> (a,[Int])

is equivalent to two functions

bar1 :: b -> a
bar2 :: b -> [Int]

and bar2 probably did not belong into the class Foo. We've been cramming to much into one typeclass and should therefore split Foo into two classes.

Olaf
_______________________________________________
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: programming style...and type classes...

Brandon Allbery
In reply to this post by Nicholls, Mark-2

On Thu, Nov 3, 2016 at 4:47 AM, Nicholls, Mark <[hidden email]> wrote:
i believe there is advice to avoid typeclasses stylistically? (see haskell wiki on style, allegedly because it leads to creeping haskell extensions...overlapping instances etc)...which lead you into the "wild" (allegedly SPJ)

Typeclasses are great when used properly and for their intended purpose. There is a tendency for new Haskellers to overuse them, or to mistake them for OOP classes and try to use them as such (which won't work, but *will* cause the compiler to start suggesting increasingly-far-afield extensions as it tries to make sense of what the programmer was trying to do).

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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: programming style...and type classes...

Nicholls, Mark-2
i like the example

but you say yourself it just means that bar2 should be elsewhere.::?

ie an oo'er would just say youve created the wrong abstraction, but not....dont create the abstraction....creating the abstraction is the mantra oo'ers are stylistically indoctonated in, in the name of extensibility (for good or evil)

so...is the problem with type classes that this modelling process is quite subtle and advanced? and thus should be avoided until you know what you're doing?
or something more?

(maybe the cost of the modelling process outweighs the benefit? even when you do know what youre doing?)


Excuse the spelling, sent from a phone with itty bitty keys, it like trying to sow a button on a shirt with a sausage.


On 3 Nov 2016, at 20:20, Brandon Allbery <[hidden email]> wrote:


On Thu, Nov 3, 2016 at 4:47 AM, Nicholls, Mark <[hidden email]> wrote:
i believe there is advice to avoid typeclasses stylistically? (see haskell wiki on style, allegedly because it leads to creeping haskell extensions...overlapping instances etc)...which lead you into the "wild" (allegedly SPJ)

Typeclasses are great when used properly and for their intended purpose. There is a tendency for new Haskellers to overuse them, or to mistake them for OOP classes and try to use them as such (which won't work, but *will* cause the compiler to start suggesting increasingly-far-afield extensions as it tries to make sense of what the programmer was trying to do).

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net



CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.

Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.

MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.


_______________________________________________
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: programming style...and type classes...

Nicholls, Mark-2
In reply to this post by Brandon Allbery

I’m nervous of the statement “used properly”…it’s a bit tautological, and the inference is often used the wrong way around…i.e. if it doesn’t work you didn’t use it properly….and if it did…then you did!

 

i.e. the logic goes.

Creating an open data abstraction is not a “proper” usage?

But not knowing future extensions requirements is a reality?

So having a language where data abstraction are open by default (unless you WANT to close them) is an attractive objective?

Typeclasses provide this?

Eureka!

Becomes DISASTER?

 

So is the objection is really empirical ?…i.e. typeclasses will cause you problems IF you work like this (and you don’t know what you’re doing)?

 

Once you know where the problems are…best steer clear….once you know the pitfalls, you can use them “properly” (successfully)?

 

(ironically the process of finding the problems IS not using them properly!...but that’s life I think).

 

 

 



CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.

Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.

MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.


_______________________________________________
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: programming style...and type classes...

Tobias Dammers
My rule of thumb is that if there is one obvious instance (or none) for
every given type, then your abstraction is a good candidate for a
typeclass; if multiple instances make sense, then it's a judgment call;
and if many instances could arbitrarily make sense or not depending on
the usage / circumstances, then it's probably not a good candidate for a
typeclass.

For example, Functor is a very good typeclass - every type can have
exactly zero or one lawful Functor instance; if you think about it a
little, this means that with Functor, you can never run into overlapping
or undecidable instances, and the open universe is a fairly benign
problem - even if you derive or implement an orphan instance, it will at
least be functionally and logically equivalent to other possible
instances.

Most of the typeclasses in base are tougher calls, but overall, I would
say they still make a lot of sense. I'd be hard pressed to come up with
a type that has more than one sensible Monad instance, for example.

Something like Aeson's ToJSON / FromJSON is kind of a judgment call -
On the one hand, they shouldn't be typeclasses, because ideally you want to
separate JSON format specifications from data types (i.e., the user code
of a given type should decide on the serialization format, not the type
itself), but on the other hand, more often than not one designs types
specifically for the purpose of representing a certain JSON schema, and
an extra translation step sits between these types and the actual domain
types (at least that's how I often do it).

On a side note; it's not like the open universe principle is a bad idea.
There are lots of benefits to be had here.

On Fri, Nov 04, 2016 at 09:57:31AM +0000, Nicholls, Mark wrote:

> I’m nervous of the statement “used properly”…it’s a bit tautological, and the inference is often used the wrong way around…i.e. if it doesn’t work you didn’t use it properly….and if it did…then you did!
>
> i.e. the logic goes.
> Creating an open data abstraction is not a “proper” usage?
> But not knowing future extensions requirements is a reality?
> So having a language where data abstraction are open by default (unless you WANT to close them) is an attractive objective?
> Typeclasses provide this?
> Eureka!
> Becomes DISASTER?
>
> So is the objection is really empirical ?…i.e. typeclasses will cause you problems IF you work like this (and you don’t know what you’re doing)?
>
> Once you know where the problems are…best steer clear….once you know the pitfalls, you can use them “properly” (successfully)?
>
> (ironically the process of finding the problems IS not using them properly!...but that’s life I think).
>
>
>
> CONFIDENTIALITY NOTICE
>
> This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.
>
> While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.
>
> Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.
>
> MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

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


--
Tobias Dammers - [hidden email]
_______________________________________________
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: programming style...and type classes...

migmit-2
More that one Monad instance is actually pretty easy: type String -> (String, a) has different monad instances if you treat it as a State monad, or as a combination of Reader and Writer. Thanks to Denis Moskvin for inspiration.


On Fri, Nov 4, 2016 at 2:29 PM, Tobias Dammers <[hidden email]> wrote:
My rule of thumb is that if there is one obvious instance (or none) for
every given type, then your abstraction is a good candidate for a
typeclass; if multiple instances make sense, then it's a judgment call;
and if many instances could arbitrarily make sense or not depending on
the usage / circumstances, then it's probably not a good candidate for a
typeclass.

For example, Functor is a very good typeclass - every type can have
exactly zero or one lawful Functor instance; if you think about it a
little, this means that with Functor, you can never run into overlapping
or undecidable instances, and the open universe is a fairly benign
problem - even if you derive or implement an orphan instance, it will at
least be functionally and logically equivalent to other possible
instances.

Most of the typeclasses in base are tougher calls, but overall, I would
say they still make a lot of sense. I'd be hard pressed to come up with
a type that has more than one sensible Monad instance, for example.

Something like Aeson's ToJSON / FromJSON is kind of a judgment call -
On the one hand, they shouldn't be typeclasses, because ideally you want to
separate JSON format specifications from data types (i.e., the user code
of a given type should decide on the serialization format, not the type
itself), but on the other hand, more often than not one designs types
specifically for the purpose of representing a certain JSON schema, and
an extra translation step sits between these types and the actual domain
types (at least that's how I often do it).

On a side note; it's not like the open universe principle is a bad idea.
There are lots of benefits to be had here.

On Fri, Nov 04, 2016 at 09:57:31AM +0000, Nicholls, Mark wrote:
> I’m nervous of the statement “used properly”…it’s a bit tautological, and the inference is often used the wrong way around…i.e. if it doesn’t work you didn’t use it properly….and if it did…then you did!
>
> i.e. the logic goes.
> Creating an open data abstraction is not a “proper” usage?
> But not knowing future extensions requirements is a reality?
> So having a language where data abstraction are open by default (unless you WANT to close them) is an attractive objective?
> Typeclasses provide this?
> Eureka!
> Becomes DISASTER?
>
> So is the objection is really empirical ?…i.e. typeclasses will cause you problems IF you work like this (and you don’t know what you’re doing)?
>
> Once you know where the problems are…best steer clear….once you know the pitfalls, you can use them “properly” (successfully)?
>
> (ironically the process of finding the problems IS not using them properly!...but that’s life I think).
>
>
>
> CONFIDENTIALITY NOTICE
>
> This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.
>
> While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.
>
> Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.
>
> MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

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


--
Tobias Dammers - [hidden email]
_______________________________________________
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: programming style...and type classes...

Nicholls, Mark-2
In reply to this post by Tobias Dammers
>Subject: Re: [Haskell-cafe] programming style...and type classes...
>
>My rule of thumb is that if there is one obvious instance (or none) for every
>given type, then your abstraction is a good candidate for a typeclass; if multiple
>instances make sense, then it's a judgment call; and if many instances could
>arbitrarily make sense or not depending on the usage / circumstances, then it's
>probably not a good candidate for a typeclass.

OK, that’s a bit more prescriptive...so if many instances make sense (Ord a) then what?

Seems like Ord is a "bad" typeclass?...it should really be a dictionary data type? And then you simply define which order you want?

There needs to be 1 (or 0) instances because this is all resolved compile time?....i.e. so we (the programmer/compiler) need a function from types, and function name into instances...if there 0 instance...then boom...not defined..so you need to do something, that’s fixable....if 2...then boom...you're in trouble?
CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.

Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.

MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.
_______________________________________________
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: programming style...and type classes...

Tobias Dammers
On Fri, Nov 04, 2016 at 02:06:18PM +0000, Nicholls, Mark wrote:

> >Subject: Re: [Haskell-cafe] programming style...and type classes...
> >
> >My rule of thumb is that if there is one obvious instance (or none) for every
> >given type, then your abstraction is a good candidate for a typeclass; if multiple
> >instances make sense, then it's a judgment call; and if many instances could
> >arbitrarily make sense or not depending on the usage / circumstances, then it's
> >probably not a good candidate for a typeclass.
>
> OK, that’s a bit more prescriptive...so if many instances make sense (Ord a) then what?
>
> Seems like Ord is a "bad" typeclass?...it should really be a dictionary data type? And then you simply define which order you want?

Ord is a "bad" typeclass if you interpret it as "the ordering rules for
this type"; but it is OK if you interpret it as "the default ordering
rules for this type". Which, arguably, makes more sense for some types
(Int) and less for others (Text). However, in the case of Ord, there is
little harm in defining a default instance and using more specialized
sorting functions that take an explicit ordering functions; this stuff
is simple enough for these things to not be very intrusive at all, and
giving arguable cases the benefit of the doubt, I guess, is considered
pragmatic.

>
> There needs to be 1 (or 0) instances because this is all resolved
> compile time?....i.e. so we (the programmer/compiler) need a function
> from types, and function name into instances...if there 0
> instance...then boom...not defined..so you need to do something,
> that’s fixable....if 2...then boom...you're in trouble?

Sort of, yes. You can't have two instances of the same typeclass for the
same type. However, because instances are always global, and can be
defined separately from both the type and the typeclass, it is possible
to write instances which, when imported, break the code that imports
them by introducing conflicting instances. This is why the
recommendation is to always define instances either in the module that
defines the type, or the module that defines the typeclass. Instances
that are defined separately from both are called "orphan instances", and
people generally avoid them where possible, but occasionally practical
concerns make them necessary. The most common reason for orphan
instances is to avoid dependencies: suppose you write a library that
defines an alternative string type; and someone else writes a library
that defines useful typeclasses for string-like types. Ideally, you want
your custom string type to have instances for those typeclasses, but you
can't put them in the typeclass library (because you don't control it),
and you don't want to put them in your own library, because then your
own library has to depend on the typeclass library even though most
people won't need that functionality. In such a situation, you'd bite
the bullet and provide an extra library that contains just the
instances, peppered with warnings about orphan instances. Another
example is when you write a program that uses types from some
third-party library, and wants to marshal them to and from JSON - for
that to work, you need to implement ToJSON and FromJSON instances for
those types, but since you control neither the type nor the JSON
typeclasses, the only choice you have is to make orphan instances in
your program. In that case, the damage is limited, because you won't
expose the orphan instances to the outside world, so it's sort of
acceptable usually.
_______________________________________________
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: programming style...and type classes...

Nicholls, Mark-2
>> >My rule of thumb is that if there is one obvious instance (or none)
>> >for every given type, then your abstraction is a good candidate for a
>> >typeclass; if multiple instances make sense, then it's a judgment
>> >call; and if many instances could arbitrarily make sense or not
>> >depending on the usage / circumstances, then it's probably not a good
>candidate for a typeclass.
>>
>> OK, that’s a bit more prescriptive...so if many instances make sense (Ord a)
>then what?
>>
>> Seems like Ord is a "bad" typeclass?...it should really be a dictionary data
>type? And then you simply define which order you want?
>
>Ord is a "bad" typeclass if you interpret it as "the ordering rules for this type";
>but it is OK if you interpret it as "the default ordering rules for this type".

:-)
This is the similar linguistic trickery as earler
You can always select a specific instance and claim it default, and then your rule of thumb becomes very very weak.

Lets order some tuples...whats the natural order?..
Ordering the natural numbers, maybe "natural" but I quite often want the reverse order, then I either build custom functions to do this, or have to map between orders (reverse).


> Which,
>arguably, makes more sense for some types
>(Int) and less for others (Text). However, in the case of Ord, there is little harm
>in defining a default instance and using more specialized sorting functions that
>take an explicit ordering functions; this stuff is simple enough for these things to
>not be very intrusive at all, and giving arguable cases the benefit of the doubt, I
>guess, is considered pragmatic.

Ok...but really your rule of thumb says "Ord" is bad...I haven’t got a problem with that...it may be "bad" but still useful enough to preserve....and the language isnt the arbiter of good practice...that's you.

Someone else has used this as a problematic typeclass in another mail (thanks).

you can decide :-)

Is Ord a bad typeclass? Or is the rule of thumb a bit weak (and allows almost any typeclass if we insert the word "default" into the spec)?

(I think Ord is a "bad" typeclass, for your heuristic to survive...and I think your heuristic captures something of value, keep the heuristic and label Ord bad...but still use it).


>
>>
>> There needs to be 1 (or 0) instances because this is all resolved
>> compile time?....i.e. so we (the programmer/compiler) need a function
>> from types, and function name into instances...if there 0
>> instance...then boom...not defined..so you need to do something,
>> that’s fixable....if 2...then boom...you're in trouble?
>
>Sort of, yes. You can't have two instances of the same typeclass for the same
>type. However, because instances are always global, and can be defined
>separately from both the type and the typeclass, it is possible to write instances
>which, when imported, break the code that imports them by introducing
>conflicting instances. This is why the recommendation is to always define
>instances either in the module that defines the type, or the module that defines
>the typeclass.


Which IS interesting.

Who's recommendation? Have you got a reference?

> Instances that are defined separately from both are called
>"orphan instances", and people generally avoid them where possible, but
>occasionally practical concerns make them necessary. The most common reason
>for orphan instances is to avoid dependencies: suppose you write a library that
>defines an alternative string type; and someone else writes a library that defines
>useful typeclasses for string-like types. Ideally, you want your custom string type
>to have instances for those typeclasses, but you can't put them in the typeclass
>library (because you don't control it), and you don't want to put them in your
>own library, because then your own library has to depend on the typeclass
>library even though most people won't need that functionality. In such a
>situation, you'd bite the bullet and provide an extra library that contains just the
>instances, peppered with warnings about orphan instances. Another example is
>when you write a program that uses types from some third-party library, and
>wants to marshal them to and from JSON - for that to work, you need to
>implement ToJSON and FromJSON instances for those types, but since you
>control neither the type nor the JSON typeclasses, the only choice you have is to
>make orphan instances in your program. In that case, the damage is limited,
>because you won't expose the orphan instances to the outside world, so it's sort
>of acceptable usually.

Ok...very interesting.

As I say if you've got a reference to some sort of "real world Haskell" book or something like that, then that’s brilliant....I can dig about the edge cases.

CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.

Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.

MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.
_______________________________________________
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: programming style...and type classes...

Will Yager
In reply to this post by Tobias Dammers


> On Nov 4, 2016, at 10:10, Tobias Dammers <[hidden email]> wrote:
>
> However, in the case of Ord, there is
> little harm in defining a default instance and using more specialized
> sorting functions that take an explicit ordering functions;

I disagree. This is the purpose of newtype wrappers. There are few scenarios where it's syntactically more convenient to pass around a bunch of random functions rather than just define a newtype with the behavior you want. GeneralizedNewtypeDeriving makes this trivial.

Will
_______________________________________________
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: programming style...and type classes...

Tobias Dammers

As with most things "apply taste" and "apply brain"... uhm... apply.


On Nov 4, 2016 6:16 PM, "Will Yager" <[hidden email]> wrote:


> On Nov 4, 2016, at 10:10, Tobias Dammers <[hidden email]> wrote:
>
> However, in the case of Ord, there is
> little harm in defining a default instance and using more specialized
> sorting functions that take an explicit ordering functions;

I disagree. This is the purpose of newtype wrappers. There are few scenarios where it's syntactically more convenient to pass around a bunch of random functions rather than just define a newtype with the behavior you want. GeneralizedNewtypeDeriving makes this trivial.

Will

_______________________________________________
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: programming style...and type classes...

Olaf Klinke
In reply to this post by Nicholls, Mark-2
While we have stated in this thread what typeclasses should _not_ be used for, we probably do not have carved out yet what `proper' use is. Please help me here.

There are some typeclasses, e.g. Eq, Ord, Num, Monoid, Functor, Monad and Category, that arise from category theory and algebra, so these may be regarded as "good" typeclasses even though a type can have several sensible instances. In that case, newtypes may express this. (Data.Monoid is full of such newtypes.)

In defense of Ord, there are in general many ways to totally order a set (read "set" as "total elements of a type"), and none of these ways can be preferred a priori. I would not say this is an inherently bad property of Ord. Similarly, there are many ways to put a monoid or ring structure on a set.

Sometimes a type class can be avoided. For example, there is Data.Foldable.toList. Hence, instead of writing a Foldable instance for your type and use a function from the Data.Foldable module, you could instead write your own toList conversion function and then fold that list. (Does anyone know a function involving Foldable that can not be reduced to 'toList' followed by some list operations? Is [] the "free instance" of Fodable?)
However, this reduction may be much more inefficient than using the Foldable instance directly.

As a contrived example of what I mean by "free instance", consider the following class that abstracts traversal over a sequence of unknown length.

class ListLike l where
  patternmatch :: l a -> Maybe (a,l a)

You can write ListLike instances for [], Vector, Sequence and Set, but only [a] is the solution to the type equation

x = Maybe (a,x).

Then there are multi-parameter type classes. This has been described as metaphorical to a type-level Prolog language [1], since ultimately multi-parameter type classes (without methods) are relations between types.

Another debatable use case: You define many record types, each of which has a sort key component:

data A = A {foo :: Foo, bar :: Bar, keyA :: Int}
data B = B {baz :: Baz, keyB :: Int}
data C = C {... , keyC :: Int}

It might be convenient to define a typeclass

class HasSortKey a where
  key :: a -> Int

and endow the types A, B and C with the obvious instances. But one could also avoid the class by making a parametric type:

data Keyed a = Keyed {payload :: a, key :: Int}

and then let data A = A {foo :: Foo, bar :: Bar} and so forth. Which version would you say is `proper' use?

-- Olaf


[1] https://www.reddit.com/r/haskell/comments/ck459/typed_typelevel_programming_in_haskell_part_i/
_______________________________________________
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: programming style...and type classes...

David Menendez-2
On Sat, Nov 5, 2016 at 11:45 AM, Olaf Klinke <[hidden email]> wrote:
While we have stated in this thread what typeclasses should _not_ be used for, we probably do not have carved out yet what `proper' use is. Please help me here.

It may be helpful to recall the original purpose of classes, which was to allow controlled, ad-hoc overloading. Otherwise, we’d be stuck using specialized functions for every type, passing around explicit equality tests, or being stuck with the equivalent of deriving(Eq) on every type.

Now that we have qualified types, we can write algorithms which are generic over class members. This, I would say, is the sign that a class is useful. If you can’t usefully write code which is generic over a class, then you don’t gain much from using the class. (You do gain not having to come up with new names, though, and that’s not nothing.)

Some people claim that you shouldn’t define a class unless you can describe some sort of algebraic laws for it, but I think that’s too strong. For one thing, it would mean we lose equality and numeric operations for Float, which is one of the things classes were invented for in the first place.

Instead, define a class if (1) you have a set of operations that can be applied at multiple types but aren’t polymorphic, (2) you can give a formal or informal description of the operations which are enough to reasonably distinguish a good instance from a bad one, and (3) using a class makes your code easier to understand.

--

_______________________________________________
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: programming style...and type classes...

Ruben Astudillo
On 06/11/16 00:06, David Menendez wrote:
> Some people claim that you shouldn’t define a class unless you can
> describe some sort of algebraic laws for it, but I think that’s too
> strong. For one thing, it would mean we lose equality and numeric
> operations for Float, which is one of the things classes were invented
> for in the first place.

I've heard that too and agree with your objection. I think what
underlies that critic, is that introduccion type classes without laws
makes it harder to see the "intuition" of what such class ought to do
(this in the context of reading, not writing). I specifically remember
being a beginners and see

    class RegexOptions regex compOpt execOpt

not understanding what really meant and why had to sprinkle it through
my code. A good case of what you say is Data.Vector.Generic.Vector,
(which argueably make more sense as a backpack-module) that makes the type
class usage intuition clear.

So in resume, what we want is "easy to understand usage" typeclasses
more than laws. To that I think putting emphasis on the important
instances goes great length in helping.

> Instead, define a class if (1) you have a set of operations that can
> be applied at multiple types but aren’t polymorphic, (2) you can give
> a formal or informal description of the operations which are enough to
> reasonably distinguish a good instance from a bad one, and (3) using a
> class makes your code easier to understand.

(2) hits the nail, specially when reading others code!

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