Re: [Haskell-cafe] Object Oriented programming for Functional Programmers

[Mike Meyer]

[Context destroyed by top posting.]
MigMit  wrote:
>But really, "Design by Contract" — a theory? It certainly is a useful
>approach, but it doesn't seem to be a theory, not until we can actually
>prove something about it, and Eiffel doesn't seem to offer anything in
>this direction.

You just stated (briefly, and not very rigorously) the theory: DbC is a useful 
approach to programing. Note that it's a theory about *programming*, not the 
resulting program.

>And by "hack" I meant not the presence of pre/postconditions, but the
>fact that they don't affect anything else. Strip all of them away, and
>you'll have the program which is, essentially, the same (and, in fact,
>pre/postconditions are supposed to be removed in the final version of
>the program). Compare this to Haskell types, for example: an untyped
>version of Haskell won't be able to choose between two class instances,
>so, that would be an entirely different language.

Type classes are the wrong feature to look at. Type signatures are closer to 
what DbC is. Are type signatures a hack to get around deficiencies in the type 
inferencing engine? After all, you can strip all of them away and have 
essentially the same program.

Personally, I think the answer is "no", and for the same reason. We add type 
signatures to top level functions because it helps document the function, and 
to help isolate type errors during compilation. They makes *programming* 
easier, even if they don't change the program at all. Pre and Post conditions 
(and class invariants - they're also part of DbC!) serve pretty much the same 
function. They help document the classes and methods, and tools that generate 
class/method documentation from source always include them. They're as 
important as the type signature. They also help isolate bugs, in that you get 
told explicitly that routine foo passed in an invalid parameter to bar rather 
than an exception somewhere deep in the guts of bar that you have to work back 
from to find foo.

As I said before, I'm not sure I agree that the latter is worth the cost of 
using them for anything complex. The bugs they uncover are as likely to be in 
the pre/post conditions as in the code proper.  The documentation benefit is 
unquestionable, though. And if some condition is worth documenting, then having 
it as executable documentation means it gets tested with the rest of the code, 
so you know the documentation is correct. Which means that just adding 
conditions to a language misses most of the benefit of DbC. You need to fix the 
documentation system as well.

This is the kind of theory that you'll find in OOSC: why the features that are 
there help make programming easier. Not theories about how they make the 
resulting program better. Those two have a lot in common, though. Anything that 
makes witing correct code easier generally results in a better program.
-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

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

Re: [Haskell-cafe] Makefile for a Haskell Project

[xuan bach]

Dear all,

Thank you for your kind replies.

I tried to used ghc --make as Mr. Scott suggested.
It is fine if in the C stub I do not call to a non-standard library of C
language.
The problem is that if I call to a non-standard C library installed (omega)
in my system,
I cannot compile it. Here is my make file using ghc make:

=
BASEDIR=/usr/local
INCS= -I$(BASEDIR)/include/omega -I.
LIBS= -L$(BASEDIR)/lib
LIB= -lcode_gen -lomega -lm

GHC=ghc

#
CFILES=$(CURDIR)/cfile
HSFILES=$(CURDIR)/hsfile
COBJFILES=$(CFILES)/termops.o $(CFILES)/termops2.o
ALLCFILES=$(CFILES)/termops.c $(CFILES)/termops2.c
#

GHC_FLAGS= -O2 -fglasgow-exts -fallow-overlapping-instances

_ffi_ex: $(COBJFILES)
ghc $(GHC_FLAGS)  -lstdc++ --make -main-is  FfiEx -o ffi_ex FfiEx.hs
$(HSFILES)/*.hs $(LIBS) $(LIB) $(COBJFILES)
=
=> * fatal error: omega.h: No such file or directory
*
Could you please give me suggestions to solve this?

Thank you.
Best Regards.
Bach.

On Fri, Dec 28, 2012 at 5:20 PM,  wrote:

> Quoting xuan bach :
>
>  Hi everyone,
>> I'm a newbie in Haskell.
>>
>> I'm wondering that if there is any tool support
>> creating Makefile for Haskell project like Ocamlbuild
>> for Ocaml project?
>>
>
> I'v just started learning how to use Neil Mitchell's Shake described at:
>
> http://neilmitchell.blogspot.**co.uk/2012/02/shake-better-**make.html
>
> Its available on hackage.
>
> Hth
>
>> Thank you,
>> Regards.
>>
>> --
>> *Le Dinh Xuan Bach*
>> *Tel: 01234711869 or +65 86967149
>> *
>> *Email: pig28...@gmail.com
>>
>> School of Information and Communication,
>> *
>> *Hanoi University of Science and Technology
>> --**--**-
>> ??
>> ?01234711869 or +65 86967149
>>   pig28...@gmail.com
>> *
>>
>>
>
>
>


-- 
*Le Dinh Xuan Bach*
*Tel: 01234711869 or +65 86967149
*
*Email: pig28...@gmail.com
School of Information and Communication,
*
*Hanoi University of Science and Technology
-
レ。ディン。スアン。バイック
電話番号：01234711869 or +65 86967149
メール：  pig28...@gmail.com
*
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Object Oriented programming for Functional Programmers

[Никитин Лев]

I said "theoratical", but not "mathematical" or "a scientific" theory.    Meyer have built a quite coherent construction in comparison with other OOP langs. BTW, when I started study haskell i had similar question: is it possible to add DbC to haskell? Does haskell need DbC?For example, class invariants may be expressed in DbC construction (fmap id = id for Functior, for example). 02.01.2013, 02:41, "Mike Meyer" :MigMit  wrote:On Jan 1, 2013, at 10:23 PM, Никитин Лев wrote: Eiffel, for my opinion, is a best OOP language. Meyer use atheoretical approach as it is possible in OOP.Really? Because when I studied it I had a very different impression:that behind this language there was no theory at all. And it's onlyfeature I remember that is not present in mainstream languages is it'spre/postconditions system, which looked like an ugly hack for me.I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to "mainstream" OO languages like C++, Java or Python, it's on a much solider theoretical basis.  Compared to something like Scheme, Haskell or even Clojure, maybe not so much.On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions is "Design by Contract". The contracts are as important as the type signature, and show up in the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as in the code.-- Sent from my Android tablet with K-9 Mail. Please excuse my swyping.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Object Oriented programming for Functional Programmers

[wren ng thornton]

On 12/31/12 4:26 PM, Rico Moorman wrote:

Hello Bob and Mike,

Reading a little within the suggested book I came across the following
statement.


We should first examine the merits and limitations of the traditional
approach: using
functions as a basis for the architecture of software systems. This will
not only lead us to
appreciate why we need something else — object technology — but also help
us avoid,
when we do move into the object world, certain methodological pitfalls
such as premature
operation ordering, which have been known to fool even experienced O-O
developers.


Because you both have more experience with this piece of literature, how
would you interpret it? With a grain of salt or would function really mean
procedure from the viewpoint of the author?


I'm not Bob nor Mike, and haven't read the text in question, but when 
you encounter "function" in most any imperative or OO setting, it almost 
certainly means a first-order procedure. No mathematical functions. No 
higher-order thingamabobs that you can pass to or return from other 
thingamabobs. Just an address in code with an expected stack frame 
configuration associated with it.



As for learning object orientation, I'd second the suggestion of 
Smalltalk. I'll leave the religious wars aside, but "OOP" means very 
different things to very different people. Most people use the term 
whilst referring to C++ and Java, but most people recognize that the 
ideological framework is best attained by Smalltalk (and related 
languages like Ruby). So, if you're interested in learning the ideology, 
then Smalltalk is a great place to get it.


Also, Smalltalk has the "become" method, which is amazing magic.

--
Live well,
~wren

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

[Haskell-cafe] hsc2hs and Storable (especially) unsafe

[Evan Laforge]

It so happens that on 64 bit OS X, haskell's Int is 64 bits, while C's int is
32 bits.  hsc2hs's #poke does no typechecking at all, so if you have

(#poke Struct, int_field) structp int -- where int :: Int

Then you probably are going to corrupt memory, and in a particularly
pernicious way (since chances are it won't segfault).  Similarly, don't poke
haskell Chars, it has to be CChar.  And what's even worse,
Foreign.withArrayLen gives you an Int, not a CInt!  So doing the obvious thing
and poking the pointer and length directly is wrong.  And besides, shouldn't
it be a CSize?  Another trap: C++'s bool is probably one byte, haskell's Bool
Storable says it's 4.  It's probably not even correct to assume Double =
CDouble and Float = CFloat, though it seems likely to be always true.

I carefully vetted all my #pokes but I'm annoyed that hsc2hs and Foreign let
me get away with this.  If Storable is for marshalling types to and from C,
then non-C types should not be Storable!  If Storable is useful for other
things (and it is!), then Foreign should define its own CStorable, that only
includes C types, and hsc2hs should use that!

While we're at it, fromIntegral is not a safe way to convert a haskell type to
a C one.  But it sure is a tempting one, because Foreign.C doesn't provide any
conversion functions (except for Bool).  We should have explicit conversion
functions that give the choice of crashing with an error or clamping the
number to the (smaller) C type's bounds.  I'm not sure if anyone wants what
fromIntegral does.

Or maybe I shouldn't be using hsc2hs in the first place.  I feel more and more
that it gives haskell a bad name, being low level and error prone.  I used
bindings-dsl for a libgit2 binding, and at least it automates Storable
instances, so it's less error-prone that way.  I'd like to generate instances
directly from .h files though, so I should probably check out c2hs.

Back in the day when I was deciding to use hsc2hs I noticed how it lacks
typechecking, but I thought that it's just a few fields, I can be careful when
writing them.  But one of the lessons from haskell (and static analysis in
general) is that "just be careful" is going to fail you some day, probably
sooner than you think.

So anyway, I wrote a ForeignC module that defines CStorable that only includes
C types.  At first I thought I could make Storable a superclass and just
re-export functions with more restritive signatures, but then it gets tricky
because you wind up needing the Storable peek and poke to declare Storable
instances.  So I defined a completely new CStorable, and all you need to do is
import ForeignC instead of Foreign, and change 'instance Storable ...' to
'instance CStorable ...'.  Unfortunately that apparently means copy-pasting
over the Storable-using utilities like 'with' and 'newArray'.

On the plus side, I dropped it into my .hsc modules, and it found several
*more* mistakes.

I was thinking of putting it on hackage (along with the conversion functions),
since other people might have made these same mistakes, but it's unpleasant
because it duplicates so much from Foreign.  Also, I only copied over the bits
I'm using, so it's not complete either.  Is there a better way to create safe
Storable instances for C?  I'd be happier with a solution that avoids the need
to write Storable instances in the first place, but hsc2hs is here now, and
used in a lot of places.

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

[Haskell-cafe] Proving programs

[Christopher Howard]

I'm working through a video lecture describing how to prove programs
correct, by first translating the program into a control flow
representation and then using propositional logic. In the control flow
section, the speaker described how the program should be understood in
terms of an input vector (X, the inputs to the program), a program
vector (Y, the storage variables), and an output vector (Z, the outputs
of the program), with X mapping into Y, Y being affected by execution,
and X and Y mapping into Z.

However, only part way into the video, two practical questions come to mind:

1. Does this approach need to be adjusted for a functional language, in
which computation is (at least idealistically) distinct from control flow?

2. How do we approach this for programs that have an input loop (or
recursion)? E.g., I have an application that reads one line for stdin,
modifies said line, outputs to stdout, and repeats this process until
EOF? Should I be thinking of every iteration as a separate program?

-- 
frigidcode.com



signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haskell Summers of Code retrospective (updated for 2012)

[Gwern Branwen]

The Wheel turns, and months come and pass, leaving web links that fade
into 403 Forbiddens; a wind rose in NYC, whispering of the coming
Winter...

As is now customary for me, I've looked into how the 2012 SoCs went -
the better to feed my misanthropic heart by mocking the students who
failed my whimsically arbitrary and subjective standards:
http://www.gwern.net/Haskell%20Summer%20of%20Code#results-2

This was not a good year. 2 students simply dropped out period, and 3
other projects turned out badly, leaving just 2 clearly successful
projects for the year. Hopefully 2013 will turn out better.

/r/haskell: 
http://www.reddit.com/r/haskell/comments/15sjur/summer_of_code_2012_retrospective/

-- 
gwern

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

Re: [Haskell-cafe] Object Oriented programming for Functional Programmers

[Bob Hutchison]

On 2013-01-01, at 3:47 PM, MigMit  wrote:

> Well, probably one of the reasons is that I've learned Eiffel later than 
> Haskell.
> 
> But really, "Design by Contract" — a theory? It certainly is a useful 
> approach, but it doesn't seem to be a theory, not until we can actually prove 
> something about it, and Eiffel doesn't seem to offer anything in this 
> direction.

Don't confuse OOSC2 and Eiffel. Eiffel implements the ideas in OOSC2 as best as 
Meyer can, but they are not the same thing.

And, personally, I think I would be willing to call DbC a theory, or a close 
precursor to a theory.

> 
> And by "hack" I meant not the presence of pre/postconditions, but the fact 
> that they don't affect anything else. Strip all of them away, and you'll have 
> the program which is, essentially, the same (and, in fact, pre/postconditions 
> are supposed to be removed in the final version of the program).

> Compare this to Haskell types, for example: an untyped version of Haskell 
> won't be able to choose between two class instances, so, that would be an 
> entirely different language.

So, I think, you're saying take away the contracts and the outcome of 
compilation won't be any different. Whereas take away the types and Haskell is 
stopped cold. And that difference makes contracts a 'hack' but types not a 
'hack'?

Seems to me you're ignoring everything that happens between an empty directory 
and a working program. Contracts help in that process (I say but can't prove). 
Call that a 'hack' if you want, but I'll take as many of those kinds of hacks 
as I can get if they're anywhere near as good as contracts.

Pre and post conditions with class invariants are neither types nor unit test, 
something in between. With the wonderful properties of 'useful' and 
'executable'.

Sometimes you just have to settle for the hacks.

Cheers,
Bob

> 
> On Jan 1, 2013, at 11:41 PM, Mike Meyer  wrote:
> 
>> 
>> 
>> MigMit  wrote:
>>> On Jan 1, 2013, at 10:23 PM, Никитин Лев 
>>> wrote:
 Eiffel, for my opinion, is a best OOP language. Meyer use a
>>> theoretical approach as it is possible in OOP.
>>> Really? Because when I studied it I had a very different impression:
>>> that behind this language there was no theory at all. And it's only
>>> feature I remember that is not present in mainstream languages is it's
>>> pre/postconditions system, which looked like an ugly hack for me.
>> 
>> I agree with Leon. Of course, I learned it out of OOSC2, which provides the 
>> theory. When compared to "mainstream" OO languages like C++, Java or Python, 
>> it's on a much solider theoretical basis.  Compared to something like 
>> Scheme, Haskell or even Clojure, maybe not so much.
>> 
>> On the other hand, one persons theory is another persons hack. The theory 
>> behind the pre/post conditions is "Design by Contract". The contracts are as 
>> important as the type signature, and show up in the auto-generated docs in 
>> eiffel systems. I found at least one attempt to add DbC features to Haskell. 
>> I'm not sold on it as a programming technique - the bugs it uncovers are as 
>> likely to be in the pre/post conditions as in the code.
>> 
>> 
>> -- 
>> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
> 
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: [Haskell-cafe] [Haskell] ANNOUNCE: graphviz-2999.15.0.0

[Ivan Lazar Miljenovic]

On 1 January 2013 22:41, Henning Thielemann
 wrote:
>
> On Tue, 1 Jan 2013, Ivan Lazar Miljenovic wrote:
>
>> After much prodding and poking by end-users for the past few months,
>> I'm finally able to announce a GHC-7.6.1 compatible release of my
>> Haskell bindings to the Graphviz graph visualisation toolkit:
>> http://hackage.haskell.org/package/graphviz-2999.15.0.0
>
>
> Did you receive my work-around for the busy-wait problem?

Whoops, forgot about that; I'll have a look now.


-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com

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

Re: [Haskell-cafe] Object Oriented programming for Functional Programmers

[MigMit]

Well, probably one of the reasons is that I've learned Eiffel later than 
Haskell.

But really, "Design by Contract" — a theory? It certainly is a useful approach, 
but it doesn't seem to be a theory, not until we can actually prove something 
about it, and Eiffel doesn't seem to offer anything in this direction.

And by "hack" I meant not the presence of pre/postconditions, but the fact that 
they don't affect anything else. Strip all of them away, and you'll have the 
program which is, essentially, the same (and, in fact, pre/postconditions are 
supposed to be removed in the final version of the program). Compare this to 
Haskell types, for example: an untyped version of Haskell won't be able to 
choose between two class instances, so, that would be an entirely different 
language.

On Jan 1, 2013, at 11:41 PM, Mike Meyer  wrote:

> 
> 
> MigMit  wrote:
>> On Jan 1, 2013, at 10:23 PM, Никитин Лев 
>> wrote:
>>> Eiffel, for my opinion, is a best OOP language. Meyer use a
>> theoretical approach as it is possible in OOP.
>> Really? Because when I studied it I had a very different impression:
>> that behind this language there was no theory at all. And it's only
>> feature I remember that is not present in mainstream languages is it's
>> pre/postconditions system, which looked like an ugly hack for me.
> 
> I agree with Leon. Of course, I learned it out of OOSC2, which provides the 
> theory. When compared to "mainstream" OO languages like C++, Java or Python, 
> it's on a much solider theoretical basis.  Compared to something like Scheme, 
> Haskell or even Clojure, maybe not so much.
> 
> On the other hand, one persons theory is another persons hack. The theory 
> behind the pre/post conditions is "Design by Contract". The contracts are as 
> important as the type signature, and show up in the auto-generated docs in 
> eiffel systems. I found at least one attempt to add DbC features to Haskell. 
> I'm not sold on it as a programming technique - the bugs it uncovers are as 
> likely to be in the pre/post conditions as in the code.
> 
> 
> -- 
> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.


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

Re: [Haskell-cafe] Object Oriented programming for Functional Programmers

[Mike Meyer]

MigMit  wrote:
>On Jan 1, 2013, at 10:23 PM, Никитин Лев 
>wrote:
>> Eiffel, for my opinion, is a best OOP language. Meyer use a
>theoretical approach as it is possible in OOP.
>Really? Because when I studied it I had a very different impression:
>that behind this language there was no theory at all. And it's only
>feature I remember that is not present in mainstream languages is it's
>pre/postconditions system, which looked like an ugly hack for me.

I agree with Leon. Of course, I learned it out of OOSC2, which provides the 
theory. When compared to "mainstream" OO languages like C++, Java or Python, 
it's on a much solider theoretical basis.  Compared to something like Scheme, 
Haskell or even Clojure, maybe not so much.

On the other hand, one persons theory is another persons hack. The theory 
behind the pre/post conditions is "Design by Contract". The contracts are as 
important as the type signature, and show up in the auto-generated docs in 
eiffel systems. I found at least one attempt to add DbC features to Haskell. 
I'm not sold on it as a programming technique - the bugs it uncovers are as 
likely to be in the pre/post conditions as in the code.


-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

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

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

[Tillmann Rendel]

Hi,

Brandon Allbery wrote:

[...] syntax extension [...]


I think someone's already working on this (SugarHaskell?).


Yes, we are working on it. See our paper [1] and Sebastian's talk [2] at 
the Haskell Symposium. Our current prototype can be installed as an 
Eclipse plugin [3] or as a command-line tool [4].


 [1] http://sugarj.org/sugarhaskell.pdf
 [2] http://www.youtube.com/watch?v=Kjm7bOLnuy0
 [3] http://update.sugarj.org/
 [4] http://hackage.haskell.org/package/sugarhaskell

One use case we have in mind for SugarHaskell is prototyping of language 
extensions like the one discussed in this thread.


  Tillmann

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

Re: [Haskell-cafe] Object Oriented programming for Functional Programmers

[MigMit]

On Jan 1, 2013, at 10:23 PM, Никитин Лев  wrote:

> Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical 
> approach as it is possible in OOP.

Really? Because when I studied it I had a very different impression: that 
behind this language there was no theory at all. And it's only feature I 
remember that is not present in mainstream languages is it's pre/postconditions 
system, which looked like an ugly hack for me.

Of course, my memory could fail me, but I doubt my tutorial did; I remember it 
being written by Meyer himself.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Object Oriented programming for Functional Programmers

[Никитин Лев]

Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP. 01.01.2013, 23:56, "Bob Hutchison" :On 2012-12-31, at 4:26 PM, Rico Moorman  wrote:Hello Bob and Mike, Reading a little within the suggested book I came across the following statement. We should first examine the merits and limitations of the traditional approach: usingfunctions as a basis for the architecture of software systems. This will not only lead us toappreciate why we need something else — object technology — but also help us avoid, when we do move into the object world, certain methodological pitfalls such as prematureoperation ordering, which have been known to fool even experienced O-O developers. Because you both have more experience with this piece of literature, how would you interpret it? With a grain of salt or would function really mean procedure from the viewpoint of the author? He is talking about functions/procedures as in C, Pascal, Algol… structured programming basically. The first edition was written in 1988, the second about 10 years later. However, today, I *think* he might include functions as found in modern functional languages in this, and as you read on in the book you'll see why I say this. I've been considering re-reading OOSC2 for a while now (it is, believe it or not, a fun book… well, maybe that's just me) and keep Haskell and ML in mind while reading it. Meyer is trying to thoroughly explain the reasoning behind OO in this book, it isn't really a critique of anything especially (except indirectly other OO languages). Meyer can be scathing but you'll have to look elsewhere for the best/worst/most fun of that. Haskell, as it matures, is going to have to have an answer for everything in this book (answers may include 'pass' as Meyer does with Eiffel on a few issues–there's no shame in admitting Haskell, or anything else, doesn't have all the answers)… he's talking about issues that are independent of programming language. Cheers,Bob Thank you very much in advance. Best regards, Rico MoormanOn Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison  wrote:On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva  wrote: Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life. So my questions for you all are:* Is it really worthwhile for me to learn OO-programming?Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big. As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big advantage to Eiffel is that you have Object Oriented Software Construction (second edition (not first)) to work from. Every OO language has to answer to the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance mechanism is also one of the few that let you use inheritance to do useful things (OOSC2 names 16 or 18 different uses for inheritance… it's not just for 'is-a' relationships). Eiffel also has a contract system that's powerful enough to be useful. Smalltalk's advantage is that it will also introduce you to the idea of a programming 'system', for lack of better words. Smalltalk works in a live system, as you are writing code you are modifying live and already executing code. Once you realize that the 'best' editor in Smalltalk is the debugger (and what 'a good debugger' actually means) you'll understand test-driven-development's origins. This is very different from Haskell. Actually, you should probably learn both languages. I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice.C you're probably going to have to learn sooner or later but wait until you have to. And it's not OO at all. Though, if you learn K&R C (pre-ansi C) you'll get a better understanding of why people liked OO so much :-) Ruby might be an easy route to OO too. I like the language quite a lot, but I'm not sure I'd recommend it for your purposes.* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers". * Is it true that learning other programming languages leads to a better use of your favorite programming language?That's been my experience. And it'll be harder to name your favourite language too.* Will I learn new programming strategies that I can use back in the Haskell world?Probably.Cheers,BobThanks in advance for your kind respo

Re: [Haskell-cafe] Mancunian Haskellers out there?

[Alfredo Di Napoli]

Wow guys,
that's a great news!
I have no experience with User Groups or sites like Meetup (the only think
I know is that a small contribution fee is required to create a Meetup), do
you have any?
Basically I think the trickiest part would be to find a place to keep the
meetings: I could ask to my employer, but it's unlikely it would gives us
permission to use company's premises outside working hours.
Any idea?

Happy new year!
A.

On 1 January 2013 18:55, David Turner  wrote:

> On 01/01/2013 16:19, Blake Rain wrote:
>
>> Hi Alfredo,
>>
>> I live in Leeds, which is not far from Manchester. I'd be up for a user
>> group nearby, so will +1 your user group :)
>>
>
> Similarly for me - I'm Leeds based and would be interested in joining in.
> Please sign me up!
>
> Cheers,
>
> David T
>
>
>> Cheers,
>>
>>
>> On 30 December 2012 15:15, Alfredo Di Napoli > >
>> wrote:
>>
>> Hey, thanks for the response :)
>> Mine was more a small survey to see if we are enough to think about
>> creating a small user group and see each other once a month or
>> whenever :)
>>
>> Cheers,
>> A.
>>
>>
>> On 30 December 2012 15:58, Mateusz Kowalczyk
>> > >
>> wrote:
>>
>> Greetings,
>> I'm currently residing in Bury, a metrolink ride away from
>> Manchester. Unfortunately, I'm only here for Christmas holidays
>> and am leaving tomorrow so a meeting is unlikely. I don't think
>> that I'd be a good conversation partner anyway as my knowledge
>> is still quite limited.
>>
>> I'd love to hear whether you find any other people though. It
>> would be nice if some Haskell talks could be held in the area if
>> there are enough people.
>>
>> Good luck on your search,
>> Mateusz Kowalczyk
>>
>>
>> On 30/12/12 14:38, Alfredo Di Napoli wrote:
>>
>>> Morning Cafe,
>>>
>>> I've been living in Manchester for 1 month now and I'm
>>> wondering if some on you are from the Greater Manchester area,
>>> so that we could chat about out beloved language in front of a
>>> glass of ale / tea :P
>>>
>>> Happy new year to everyone!
>>> A.
>>>
>>>
>>> __**_
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org  
>>> >> >
>>> 
>>> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>>>
>>
>>
>>
>> __**_
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org 
>> > >
>>
>> 
>> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>>
>>
>>
>>
>> __**_
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>>
>>
>
> --
> David Turner
> Senior Consultant
> Tracsis PLC
>
> Tracsis PLC is a company registered in
> England and Wales with number 5019106.
>
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Mancunian Haskellers out there?

[David Turner]

On 01/01/2013 16:19, Blake Rain wrote:

Hi Alfredo,

I live in Leeds, which is not far from Manchester. I'd be up for a user
group nearby, so will +1 your user group :)


Similarly for me - I'm Leeds based and would be interested in joining 
in. Please sign me up!


Cheers,

David T



Cheers,


On 30 December 2012 15:15, Alfredo Di Napoli mailto:alfredo.dinap...@gmail.com>> wrote:

Hey, thanks for the response :)
Mine was more a small survey to see if we are enough to think about
creating a small user group and see each other once a month or
whenever :)

Cheers,
A.


On 30 December 2012 15:58, Mateusz Kowalczyk
mailto:fuuze...@fuuzetsu.co.uk>> wrote:

Greetings,
I'm currently residing in Bury, a metrolink ride away from
Manchester. Unfortunately, I'm only here for Christmas holidays
and am leaving tomorrow so a meeting is unlikely. I don't think
that I'd be a good conversation partner anyway as my knowledge
is still quite limited.

I'd love to hear whether you find any other people though. It
would be nice if some Haskell talks could be held in the area if
there are enough people.

Good luck on your search,
Mateusz Kowalczyk


On 30/12/12 14:38, Alfredo Di Napoli wrote:

Morning Cafe,

I've been living in Manchester for 1 month now and I'm
wondering if some on you are from the Greater Manchester area,
so that we could chat about out beloved language in front of a
glass of ale / tea :P

Happy new year to everyone!
A.


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




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




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




--
David Turner
Senior Consultant
Tracsis PLC

Tracsis PLC is a company registered in
England and Wales with number 5019106.

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

Re: [Haskell-cafe] Mancunian Haskellers out there?

[Arthur Clune]

I'm in York and would love to meet up

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

Re: [Haskell-cafe] Object Oriented programming for Functional Programmers

[Bob Hutchison]

On 2012-12-31, at 4:26 PM, Rico Moorman  wrote:

> Hello Bob and Mike,
> 
> Reading a little within the suggested book I came across the following 
> statement.
> 
> We should first examine the merits and limitations of the traditional 
> approach: using
> functions as a basis for the architecture of software systems. This will not 
> only lead us to
> appreciate why we need something else — object technology — but also help us 
> avoid,
> when we do move into the object world, certain methodological pitfalls such 
> as premature
> operation ordering, which have been known to fool even experienced O-O 
> developers.
> 
> Because you both have more experience with this piece of literature, how 
> would you interpret it? With a grain of salt or would function really mean 
> procedure from the viewpoint of the author?

He is talking about functions/procedures as in C, Pascal, Algol… structured 
programming basically. The first edition was written in 1988, the second about 
10 years later. However, today, I *think* he might include functions as found 
in modern functional languages in this, and as you read on in the book you'll 
see why I say this. I've been considering re-reading OOSC2 for a while now (it 
is, believe it or not, a fun book… well, maybe that's just me) and keep Haskell 
and ML in mind while reading it. Meyer is trying to thoroughly explain the 
reasoning behind OO in this book, it isn't really a critique of anything 
especially (except indirectly other OO languages). Meyer can be scathing but 
you'll have to look elsewhere for the best/worst/most fun of that. Haskell, as 
it matures, is going to have to have an answer for everything in this book 
(answers may include 'pass' as Meyer does with Eiffel on a few issues–there's 
no shame in admitting Haskell, or anything else, doesn't have all the answers)… 
he's talking about issues that are independent of programming language.

Cheers,
Bob

> 
> Thank you very much in advance.
> 
> Best regards,
> 
> Rico Moorman
> 
> On Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison  
> wrote:
> On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva  
> wrote:
> 
>> Well, my curiosity is bringing me to learn a new general purpose programming 
>> language. Haskellers are frequently comparing Object-Oriented languages with 
>> Haskell itself, but I have never programmed in any OO-language! (perhaps 
>> this is an uncommon case) I thought it could be good to me (as a programmer) 
>> to learn C/C++. Many interesting courses (most of them) use these languages 
>> and I feel like limited for being a Haskell programmer. It looks like I have 
>> to learn imperative programming (with side effects all over around) in some 
>> point of my programming life.
>> 
>> So my questions for you all are:
>> 
>> * Is it really worthwhile for me to learn OO-programming?
> 
> Yes. And you should learn OO *very* well. And remember, OO doesn't really get 
> interesting until the program gets big.
> 
> As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big 
> advantage to Eiffel is that you have Object Oriented Software Construction 
> (second edition (not first)) to work from. Every OO language has to answer to 
> the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance 
> mechanism is also one of the few that let you use inheritance to do useful 
> things (OOSC2 names 16 or 18 different uses for inheritance… it's not just 
> for 'is-a' relationships). Eiffel also has a contract system that's powerful 
> enough to be useful. Smalltalk's advantage is that it will also introduce you 
> to the idea of a programming 'system', for lack of better words. Smalltalk 
> works in a live system, as you are writing code you are modifying live and 
> already executing code. Once you realize that the 'best' editor in Smalltalk 
> is the debugger (and what 'a good debugger' actually means) you'll understand 
> test-driven-development's origins. This is very different from Haskell. 
> Actually, you should probably learn both languages.
> 
> I don't think C++ will help you learn OO, or much of anything else either. 
> Vigorously avoid is my advice.
> 
> C you're probably going to have to learn sooner or later but wait until you 
> have to. And it's not OO at all. Though, if you learn K&R C (pre-ansi C) 
> you'll get a better understanding of why people liked OO so much :-)
> 
> Ruby might be an easy route to OO too. I like the language quite a lot, but 
> I'm not sure I'd recommend it for your purposes.
> 
> 
>> 
>> * If so, where should I start? There are plenty of "functional programming 
>> for OO programmers" but I have never seen "OO programming for functional 
>> programmers".
>> 
>> * Is it true that learning other programming languages leads to a better use 
>> of your favorite programming language?
> 
> That's been my experience. And it'll be harder to name your favourite 
> language too.
> 
> 
>> 
>> * Will I learn new programming strategies that I can use back in th

Re: [Haskell-cafe] Mancunian Haskellers out there?

[Blake Rain]

Hi Alfredo,

I live in Leeds, which is not far from Manchester. I'd be up for a user
group nearby, so will +1 your user group :)

Cheers,


On 30 December 2012 15:15, Alfredo Di Napoli wrote:

> Hey, thanks for the response :)
> Mine was more a small survey to see if we are enough to think about
> creating a small user group and see each other once a month or whenever :)
>
> Cheers,
> A.
>
>
> On 30 December 2012 15:58, Mateusz Kowalczyk wrote:
>
>>  Greetings,
>> I'm currently residing in Bury, a metrolink ride away from Manchester.
>> Unfortunately, I'm only here for Christmas holidays and am leaving tomorrow
>> so a meeting is unlikely. I don't think that I'd be a good conversation
>> partner anyway as my knowledge is still quite limited.
>>
>> I'd love to hear whether you find any other people though. It would be
>> nice if some Haskell talks could be held in the area if there are enough
>> people.
>>
>> Good luck on your search,
>> Mateusz Kowalczyk
>>
>>
>> On 30/12/12 14:38, Alfredo Di Napoli wrote:
>>
>> Morning Cafe,
>>
>>  I've been living in Manchester for 1 month now and I'm wondering if
>> some on you are from the Greater Manchester area, so that we could chat
>> about out beloved language in front of a glass of ale / tea :P
>>
>>  Happy new year to everyone!
>> A.
>>
>>
>> ___
>> Haskell-Cafe mailing 
>> listHaskell-Cafe@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Haskell-beginners] ghc and android

[Brandon Allbery]

On Tue, Jan 1, 2013 at 9:13 AM, Bernhard Urban  wrote:

> The main issue: The GHC runtime relies on glibc
>

I have to assume this is not meant literally, because ghc works on OS X and
*BSD.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Haskell-beginners] ghc and android

[Bernhard Urban]

On Tue, Jan 1, 2013 at 1:13 PM, Ivan Perez  wrote:
> Please, let us know if you manage to compile it.

There are some comments regarding porting git-annex to android, in
order to make it useable from shell (that is, not as android app).
http://git-annex.branchable.com/design/assistant/android/

The main issue: The GHC runtime relies on glibc, which is not used on
android. Also, glibc cannot be (fully) linked statically.
Probably someone with more knowledge about GHC internals and glibc can
came up with a clean solution to this problem.


> An additional issue:  ghci (and Template Haskell because it uses the
> bytecode interpreter of ghci internally) currently(?) requires its own
> custom linker instead of being able to use the system linker.  Said linker
> has no support for ARM.  The correct fix for this is to redesign ghci so it
> doesn't need its own linker; there has been some work in this direction,
> but I don't know how complete it is, and it interacts with other issues
> such as building Haskell libraries as shared objects.

http://www.haskell.org/pipermail/glasgow-haskell-users/2012-December/023163.html
I don't know the situation on ARM though.


I added ghc-users mailinglist to CC.


Regards,
Bernhard

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

Re: [Haskell-cafe] Backtracking in HXT

[Mateusz Kowalczyk]

Ah, zeroArrow looks exactly like what I need here!

Thanks, this helps.

Mateusz Kowalczyk

On 01/01/13 01:08, dag.odenh...@gmail.com wrote:

(">>>" is my GHCi prompt, might be a bit confusing for an arrow example.)


On Tue, Jan 1, 2013 at 2:05 AM, dag.odenh...@gmail.com 
 > wrote:


Use arrow notation and zeroArrow, like so:

{-# LANGUAGE Arrows #-}
import Text.XML.HXT.Core
getA =
  hasName "a" >>> proc elem -> do
text <- getText <<< getChildren -< elem
if text == "Hello Two!"
  then getAttrValue "href" -< elem
  else zeroArrow -< ()

>>> runX $ readString  [] "Hello One!Hello Two!" >>>
deep getA
["example.com/anotherlink.html "]



On Mon, Dec 31, 2012 at 3:36 PM, Mateusz Kowalczyk
mailto:fuuze...@fuuzetsu.co.uk>> wrote:

Hello,
I'm not sure if this is the right place to ask this but here goes.

I'm currently working with HXT and I quite like it. There's
one issue I
can't solve (at least now without some dirty, dirty hacking)
and I'm
sure it's fairly simple.

Consider the following mark-up

http://example.com/somelink.html>">Hello One!
http://example.com/anotherlink.html>">Hello Two!

Now, what I'm trying to achieve is to get the href based on
the text. I
can test for what the text is by traversing s, then using the
getChildren >>> getText arrow. What I can't figure out is how
to check
the text and then get the href as by the time I get to the
text, I'll
further down the tree!

I imagine it would look something along the lines of
 (getChildren >>> getText  "Hello Two") `guards` getAttrValue
"href".  is just a random operator I made up for illustration
purposes that works as a predicate over arrows.

Is this the right approach? Is there a built-in that already
does what I want? It
seems like a common task...

Mateusz Kowalczyk

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





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

Re: [Haskell-cafe] [Haskell] ANNOUNCE: graphviz-2999.15.0.0

[Henning Thielemann]

On Tue, 1 Jan 2013, Ivan Lazar Miljenovic wrote:


After much prodding and poking by end-users for the past few months,
I'm finally able to announce a GHC-7.6.1 compatible release of my
Haskell bindings to the Graphviz graph visualisation toolkit:
http://hackage.haskell.org/package/graphviz-2999.15.0.0


Did you receive my work-around for the busy-wait problem?

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

Re: [Haskell-cafe] [Haskell-beginners] ghc and android

[Ivan Perez]

Nathan,
 David is right. Using the x86 Android image in a VM could be fast
enough (if you computer has virtualization support)

I haven't tried to compile GHC for android myself. At the present
time, and taking into account that it would probably be slow to
execute and lack all the interesting libraries that I would like to
use, other FP languages may be better choices.

Please, let us know if you manage to compile it.

Cheers,
Ivan

On 31 December 2012 19:04, David Thomas  wrote:
> Couldn't that simply be simulated?
>
>
> On Mon, Dec 31, 2012 at 2:36 PM, Nathan Hüsken 
> wrote:
>>
>> That seems almost impossible, I would need an android device with unusual
>> capacity.
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

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