Re: [Haskell-cafe] NaN as Integer value

[Gabriel Dos Reis]

On Sun, Apr 14, 2013 at 7:53 PM, Kim-Ee Yeoh  wrote:
> On Sun, Apr 14, 2013 at 3:28 PM, wren ng thornton  wrote:
>> Whereas the problematic
>> values due to infinities are overspecified, so no matter which answer you
>> pick it's guaranteed to be the wrong answer half the time.
>>
>> Part of this whole problem comes from the fact that floats *do* decide to
>> give a meaning to 1/0 (namely Infinity).
>
> I'm not sure what you mean about overspecification here, but in
> setting 1/0 as +infinity (as opposed to -infinity), there's an easily
> overlooked assumption that the limit is obtained "from above" as
> opposed to "from below."

Not quite.  0.0 designates "positive zero" or +0.0 in IEEE 754 notation.
There is also "negative zero" or -0.0 in IEEE 754 notation.  If you want
the limit from below, use negative zero.  This is all standard IEEE
754 concepts.

-- Gaby

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] C++ class = neutered (haskell class + haskell existential)

[Gabriel Dos Reis]

John Meacham <[EMAIL PROTECTED]> writes:

| I was mainly specifically comparing haskell to standard OOP classes,
| 
| Most OOP languages certainly have some set of other features in addition,
| such as forms of ad hoc polymorphism or the template meta-language of
| C++, or the code reuse primitives in sather, however I was mainly
| interested in exploring base OOP and its relation to haskell
| typeclasses. As it seems to come up a lot. 
| 
| C++ templates are a whole nother ball of wax.

I believe you should not eliminate C++ templates from "standard OO"
classes -- for example, the C++ IOStream hierarchy is an example of
"standard OO" -- at least if you want to discuss "OOP" with C++ :-)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] C++ class = neutered (haskell class + haskell existential)

[Gabriel Dos Reis]

Bulat Ziganshin <[EMAIL PROTECTED]> writes:

| Hello Gabriel,
| 
| Sunday, August 20, 2006, 8:26:30 AM, you wrote:
| 
| > | There is a major difference though, in C++ (or java, or sather, or c#,
| > | etc..) the dictionary is always attached to the value, the actual class
| > | data type you pass around.
| 
| > The dictionary can be attached to the operations (not just to the values) by
| > using objects local to functions (which sort of matierialize the
| > dictionary).
| 
| This means that type classes can be _emulated_ in C++. but the bare
| semantics is just as we said - in Haskell dictionaries are passed
| around the functions (unless existential used) and in C++ they are
| attached to objects
| 
| i agree that emulation you provided is closer to type classes at least
| in that it implements _dynamic_ dispatching vs compile-time
| dispatching of templates. but typical C++ programming involves using
| classes and templates, not the unusual technique you have introduced.

Who knows what "typical C++ programming" is?

I don't think what I showed is unusual.  As a matter of fact, it is just
a dynamic version of trait techniques (which as I understood inspired
AT for Haskell).  I don't think I invented anything new or unusual here.
I most certainly have seen similar techniques in production codes
years ago.  You should not dismiss it as unusual because you might not
be familiar with it.  

As for the comparison with function to pointers, well it is a familiar
argument: just because we had function to pointer means we could not have 
virtual functions :-)  As a matter of fact, virtual functions provide
invariants that are hard or impossible to attain with pointers to
functions.  Similarly, I would find it more useful to see an analysis
of invariants type classes provide (to support programming
techniques) that are hard or impossible to attain with mere
parameterized classes, than surface comparison of language features.

My opinion is that comparison of language feature for language
language is often a hard and meaningless exercise.  I find it more
interesting to focus of programming *techniques* supported by language
features.  Such a comparison usually does not need exact
correspondence of feature for feature.  No doubt, this is not an easy
exercise either. 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] C++ class = neutered (haskell class + haskell existential)

[Gabriel Dos Reis]

Bulat Ziganshin <[EMAIL PROTECTED]> writes:

| Hello John,
| 
| Friday, August 18, 2006, 5:16:45 AM, you wrote:
| 
| > There is a major difference though, in C++ (or java, or sather, or c#,
| > etc..) the dictionary is always attached to the value, the actual class
| > data type you pass around. in haskell, the dictionary is passed
| > separately and the appropriae one is infered by the type system.
| 
| your letter is damn close to that i wrote in
| http://haskell.org/haskellwiki/OOP_vs_type_classes
| although i mentioned not only pluses but also drawbacks of type
| classes: lack of record extension mechanisms (such at that implemented
| in O'Haskell) and therefore inability to reuse operation
| implementation in an derived data type, lack of downcasting mechanism
| (which bites me all the way), requirement to rebuild dictionaries in
| polymorphic operations what is slow enough

I would appreciate if you could revise the comparison based on the
material I just sent, that illustrates my earlier comments.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] C++ class = neutered (haskell class + haskell existential)

[Gabriel Dos Reis]

Bulat Ziganshin <[EMAIL PROTECTED]> writes:

| Hello Thomas,
| 
| Friday, August 18, 2006, 7:57:13 AM, you wrote:
| 
| >> There is a major difference though, in C++ (or java, or sather, or c#,
| >> etc..) the dictionary is always attached to the value, the actual class
| >> data type you pass around. in haskell, the dictionary is passed
| >> separately and the appropriae one is infered by the type system. C++
| >> doesn't infer, it just assumes everything will be carying around its
| >> dictionary with it.
| 
| > C++ programmers deal with this using a number of techniques, mostly
| > involving templates.
| 
| Haskell type classes are closer to templates/generics than to classes
| itself

I believe Haskell type classes are closer to *parameterized abstract
classes* than to classes.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] C++ class = neutered (haskell class + haskell existential)

[Gabriel Dos Reis]

John Meacham <[EMAIL PROTECTED]> writes:

| On Tue, Aug 15, 2006 at 08:36:28PM +0200, Gabriel Dos Reis wrote:
| > Roughly Haskell type classes correspond to parameterized abstract
| > classes in C++ (i.e. class templates with virtual functions 
| > representing the operations).  Instance declarations correspond to
| > derivation and implementations of those parameterized classes.
| 
| There is a major difference though, in C++ (or java, or sather, or c#,
| etc..) the dictionary is always attached to the value, the actual class
| data type you pass around.

I suspect that most of the confusion come from the fact that people
believe just because virtual functions are attached to objects, 
they cannot attach them to operations outside classes.  That, to my
surprise, hints at a deeper misappreciation of both type classes and
so-called "OO" technology.  Type classes are more OO than one might
realize. 

The dictionary can be attached to the operations (not just to the values) by
using objects local to functions (which sort of matierialize the
dictionary).  Consider

// Abstract class for a collection of classes that implement
// the "Num" mathematical structure
template
  struct Num {
  virtual T add(T, T) const = 0;
  };

// Every type must specialize this class template to assert
// membership to the "Num" structure.  
template struct Num_instance;

// The operation "+" is defined for any type that belongs to "Num".
// Notice, membership is asserted aby specializing Num_instance<>.
template
  T operator+(T lhs, T rhs)
  {
 const Num_instance instance;  
 return instance.add(lhs, rhs);
  }

// "Foo" is in "Num"
struct Num_instance : Num {
   Foo add(Foo a, Foo b) const { ... }
};


The key here is in the definition of operator+ which is just a formal
name for the real operation done by instance.add().

I appreciate that inferring and building the dictionary (represented
here by the "instance" local to operator+) is done automatically by
the Haskell type system.
That is  one of the reasons why the type class notation is a nice sugar.
However, that should not distract from its deerper OO semantics.


[...]

| in haskell you can do
| 
| class Monoid a where
| mempty :: a
| 
| in OOP, this cannot be done because where does the dicionary come from?

See above.  I believe a key in my suggestion was "paramaterized
abstract classes", not just "abstract classes".
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: OOP vs type classes Re[2]: [Haskell-cafe] type gurus, can you please help?

[Gabriel Dos Reis]

Bulat Ziganshin <[EMAIL PROTECTED]> writes:

| Hello Gabriel,
| 
| Tuesday, August 15, 2006, 10:36:28 PM, you wrote:
| 
| > | Moreover, Haskell type classes supports inheritance. Run-time
| > | polymorphism together with inheritance are often seen as OOP
| > | distinctive points, so during long time i considered type classes as a
| > | form of OOP implementation. but that's wrong! Haskell type classes
| > | build on different basis, so they are like C++ templates with added
| > | inheritance and run-time polymorphism! And this means that usage of
| > | type classes is different from using classes, with its own strong and
| > | weak points.
| 
| > Roughly Haskell type classes correspond to parameterized abstract
| > classes in C++ (i.e. class templates with virtual functions 
| > representing the operations).  Instance declarations correspond to
| > derivation and implementations of those parameterized classes.
| 
| i can't agree. 

You're welcome :-)

| the differences between TC inheritance/polymorphism and
| C++ classes are substantial. i listed them in next part of tutorial which
| you should see alongside this message.

sorry, I did not see that tutorial.

| you can also see paper at
| http://homepages.cwi.nl/~ralf/gpce06/ which is all about consequences
| of differences between classes and type classes for software
| development

Thanks for the reference.  Nothing in that paper explores what I
suggested.  I don't see how it contradicts what I said.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] type gurus, can you please help?

[Gabriel Dos Reis]

Bulat Ziganshin <[EMAIL PROTECTED]> writes:

[...]

| Moreover, Haskell type classes supports inheritance. Run-time
| polymorphism together with inheritance are often seen as OOP
| distinctive points, so during long time i considered type classes as a
| form of OOP implementation. but that's wrong! Haskell type classes
| build on different basis, so they are like C++ templates with added
| inheritance and run-time polymorphism! And this means that usage of
| type classes is different from using classes, with its own strong and
| weak points.

Roughly Haskell type classes correspond to parameterized abstract
classes in C++ (i.e. class templates with virtual functions 
representing the operations).  Instance declarations correspond to
derivation and implementations of those parameterized classes.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Preventing/handling space leaks

[Gabriel Dos Reis]

Fergus Henderson <[EMAIL PROTECTED]> writes:

| Even the C++ standard library itself, which has been
| subject to review by the world's best C++ experts, suffers
| from exception safety problems.  A new exception safety
| problem with std::auto_ptr was discovered just last Friday!  See
| .
| 
| Note that this class has already been the subject of extensive analysis
| of its exception safety, and indeed the only reason that auto_ptr
| was introduced in the first place was in an attempt to help guarantee
| exception safety!

I think it is fair to characterize auto_ptr as a curiously broken
class since its conception and design.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe