Invisible <voi### [at] devnull> wrote:
> For a start, F# is functional in the same way that C++ is 
> object-oriented. I.e., not very. F# is a normal OO language with a few 
> slightly functional ideas bolted on the side as an afterthought.

  When will we see the Haskell# language?

-- 
                                                          - Warp

Post a reply to this message

Invisible escreveu:
> ...and then I feel depressed because I'm the only person in the UK who 
> programs in Haskell

you and at least Simon Peyton Jones.

Post a reply to this message

scott escreveu:
> If Haskell had a decent IDE and easy documented access to the rest of 
> the system I might consider using it.  But then F# exists already and I 
> haven't paid much attention to that so far...

IDEs are only really useful for OO languages.  You know, you have a 
variable holding an instance of a class, then you type "." and get a 
list of methods available... no such thing in functional programming 
where the order is reversed:  you have a function and want to apply 
arguments to it.  You may list arguments that match that function 
definition and you may even know their types (assuming "intellisense" 
got type inference), but most likely you're not directly applying those 
arguments to the function, but applying some other function to it first. 
  It sounds too much of hassle to use "intellisense" in those situations...

I fear IDEs are really only useful at getting away with lesser 
languages' weaknesses, AKA boilerplate cruft to make the compiler happy. 
  In Java, most of the IDE is used not just for that but also to handle 
all the xml needed, since it's the only DSL known to java-heads...

so, all that would seem to rest of usefulness for an IDE is project 
management.  Here too it proves pretty useless as it's only really 
needed to manage huge bloated projects full of boilerplate and xml.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I'm still a bit baffled that this is a valid thing to do, however...

  There's some baggage from C that would have better been dropped, but
as you may know, backwards compatibility can be a real b***h sometimes...

  It can be argued using the same logic as with uninitialized variables,
though: There are situations where execution never reaches the end of the
function, and hence having a 'return' statement there would be useless.
In most situations putting such a useless 'return' there is only a minor
inconvenience, but in theory it could be more complicated. Also, it makes
the function larger, so the 80's C hackers didn't like that (in the same
way as they didn't like the idea of spending a clock cycle to initialize
a variable with a value that would immediately be overwritten anyways).

  This would be an example of such a function:

std::string foo(int parameter)
{
    assert(parameter >= 0 && parameter < 4);
    switch(parameter)
    {
     case 0: return "Hello";
     case 1: return "there";
     case 2: return "world";
     case 3: return "!";
    }

    // Execution will *never* reach here
    // It's valid to omit a 'return'
}

-- 
                                                          - Warp

Post a reply to this message

Le 17/04/2012 21:51, Warp nous fit lire :
> the 80's C hackers didn't like that (in the same
> way as they didn't like the idea of spending a clock cycle to initialize
> a variable with a value that would immediately be overwritten anyways).

It was a time where memory access was done by putting the address on the
address bus, and the data was read/write on the data bus (and a wire was
dedicated to indicate if it was a read or write).
A time in which the memory respond time was faster than the CPU clock.
A time you could know the number of cycles to perform an addition, a
multiplication or a division (on integer). And gains a few cycles by
reordering expression.

A time I remember!

And it cost one cycle (may be a bit more, I do not remember the timing
for a move.l) to write a zero to a data bus-wide variable, but as many
cycles for an array. You do not want to waste 40 cycles to erase an
array of 40 int.

You already wasted a cycle to increase the stack usage, and by entering
a function you wasted a few more cycle saving a few registers on it too.

Post a reply to this message

Le 17/04/2012 14:13, Invisible a écrit :
> Obviously this /isn't/ what's so special about classes. The /actual/
> benefits don't appear to be mentioned.

The benefit of class over a simple struct/collection is in the
private/protected parts, and the mandatory centralisation of the
prototypes of all related functions (until you start playing with
friend, but that's another story).

The point in class is to separate the interface (how the outside world
see me and use me) from the implementation (how I do it internally).

Once exposed, the public interface must remain (it can be expanded, but
not changed drastically).
The implementation can be changed at any time.

And then we are going to enter some holy wars about automatic getter &
setter, and static member in class.


-- 
A good Manager will take you
through the forest, no mater what.
A Leader will take time to climb on a
Tree and say 'This is the wrong forest'.

Post a reply to this message

On 17/04/2012 08:09 PM, nemesis wrote:
> Invisible escreveu:
>> ...and then I feel depressed because I'm the only person in the UK who
>> programs in Haskell
>
> you and at least Simon Peyton Jones.

Yeah - I should go visit that guy sometime...

Post a reply to this message

On 17/04/2012 05:07 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> For a start, F# is functional in the same way that C++ is
>> object-oriented. I.e., not very. F# is a normal OO language with a few
>> slightly functional ideas bolted on the side as an afterthought.
>
>    When will we see the Haskell# language?

Well, a while back somebody did do a Haskell to .NET bridge for their 
PhD thesis.

(A /bridge/ is of course not the same thing as compiling to CIL. The 
Haskell stuff runs as normal, it's just that it can "talk to" stuff 
running on the .NET platform.)

Naturally, being a PhD thesis, it's proof-of-concept, not 
production-grade. And, I would imagine, no longer maintained. (Not that 
I suppose the /code/ was ever publicly released. The /thesis/ was, but I 
don't know about the runnable code.)

In a similar vein, one of the experimental Haskell compilers has a 
JavaScript back-end. As in, you write your Haskell program, compile it, 
and you get (several KB of) normal JavaScript which will run in any web 
browser. Again, not exactly production-grade, but interesting.

I think somebody somewhere once had a Haskell to Java compiler. (Or, 
more likely, a "small subset of Haskell to Java compiler".) Highly 
unfinished, of course.

Perhaps it would make an interesting research project... Maybe I should 
look up how either Java bytecodes or the CIL works, and write some code 
to target it.

Naturally, being able to run on either the JVM or the CLR wouldn't be 
interesting unless it's also simple and easy to access the existing 
class libraries. And that's another interesting project.

Post a reply to this message

On 17/04/2012 08:51 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> I'm still a bit baffled that this is a valid thing to do, however...
>
>    There's some baggage from C that would have better been dropped, but
> as you may know, backwards compatibility can be a real b***h sometimes...

Don't we all know it. ;-)

(Haskell isn't as ancient as C, so fortunately it has much less of this. 
It /does/ have it, however...)

>    It can be argued using the same logic as with uninitialized variables,
> though: There are situations where execution never reaches the end of the
> function, and hence having a 'return' statement there would be useless.

Sure. But like I said, the Java compiler seems to detect this. If 
doesn't just look at a function and say "does it contain a return 
statement somewhere?" It actually statically analyses every possible 
flow of control, and checks that every individual one ends with a return 
(or throws an exception, which is also a valid way to terminate a function).

Of course, it's not perfect. Plausibly you could have if branches such 
that a particular sequence of branches is impossible due to the 
conditions in those branches, but the compiler wouldn't "see" that and 
would still insist that you have a branch that doesn't terminate 
properly. But I haven't seen that happen yet.

Post a reply to this message

On 18/04/2012 07:24 AM, Le_Forgeron wrote:
> Le 17/04/2012 14:13, Invisible a écrit :
>> Obviously this /isn't/ what's so special about classes. The /actual/
>> benefits don't appear to be mentioned.
>
> The benefit of class over a simple struct/collection is in the
> private/protected parts, and the mandatory centralisation of the
> prototypes of all related functions.

Indeed. Anybody who knows any OO theory will understand this. But, 
unfortunately, anyone who reads this book will have no idea.

Hey Warp, you ever think about writing a book? I bet you could do a 
better job than this idiot...

Post a reply to this message