Re: Function minimization and random numbers

Jon Harrop <usenet@xxxxxxxxxxxxxx> wrote:
However, that seems irrelevant in terms of the question of whether C#
lacks closures. You claim that it does, and I'll ask again: please
provide some widely accepted definition of "closure" which C# doesn't
satisfy.

Delegates are second class constructs, incompatible with other kinds of
functions (members) due to the problem you just described.

What "problem"? I don't remember describing a problem.

That is why you must convert a member into a delegate manually in C#
when, in fact, they are both just functions. There's a whole MSDN help
page devoted to this no-op.

What exactly do you mean by "manually"?

The programmer has to do something: the task is not automated by the
compiler.

The compiler performs implicit conversions from method groups and
anonymous functions to delegates.

Do you mean there has to be an
appropriate delegate type to convert to? That's certainly true. I don't
see the issue though - unless you want to do away with static type
safety, there has to be something available to encapsulate the
signature of the function.

You only need a single generic function type:

'a -> 'b

There is no loss of static type safety.

You only need a single generic function if you only want a single
parameter. How can you tell the difference between a function taking
two integers and a function taking two strings in F#? Or do functions
only ever take a single parameter which then has to be a tuple if it
needs more than one piece of information? That sounds to me like it's
just pushing the problem down to defining the tuple.

Now, you could well want to do away with the static type safety -

I want a more expressive type system that offers more static type safety.

Groovy supports overloaded method groups as closures, where the
appropriate method to actually call is determined at execution time,
for example. There are advantages and disadvantages to that - but I
haven't seen anything in a definition of closures which *requires* a
dynamic interface.

There are lots of statically-typed functional programming languages: OCaml,
SML, Haskell, F#.

Okay, so if it's not static typing that's the problem, I'll ask again
what you actually can't do with C#. You haven't given a straight answer

Anonymous methods and lambda expressions were added with no thought
whatsoever.

On the contrary, Microsoft have put a lot of thought into their language
design but it culminated in F# rather than delegates. :-)

You know perfectly well I was referring to C# - you've just ducked the
question instead of admitting that your previous post was mere
hyperbole.

(You'd increase your credibility by also admitting that C# really
*does* support closures and your claim that it doesn't was also just
hyperbole.)

Provided you just want a list of checkboxes of
language features, that's fine, but if you want the features to be useful
then you're going to have to think a lot more about how they interact.

Are you claiming that the C# support for closures is useless? That
would rule out most of LINQ to start with...

Relegating functions to second-class citizens makes functional programming
unnecessarily tedious.

While it's true that I wouldn't use C# if I wanted a language which is
primarily designed for functional programming, C# 3 works very well as
a language which lets you use a functional style when you want to and
an OO/imperative style where that's more appropriate.

Claiming that C# lacks closures is pure FUD in my view.

Avoid closures if you want to call your F# libraries from C#.

So has F# eschewed the standard .NET use of delegates as effectively
function pointers? If F# really doesn't allow the use of what *the
whole of the rest of .NET* treats as functions to be treated as
functions, that sounds like F#'s fault rather than C#'s. However, I
seem to remember that actually you *can* use delegates in F# perfectly
easily. I'd check with Robert's book, but it's at work at the moment.

F# programs can define and use delegates but F#'s closures are not
delegates.

So F# can't pass a closure to a method which takes a delegate
parameter? That's a pity, given LINQ etc.

Perhaps you'd deign to explain to us mere peasants just why F#'s
support of closures is so wonderful as to make C#'s support appear to
be useless and to even count as a lack of support in your (previously
stated) view.

Look at parser combinators, for example.

No, you forget - we're stupid people, remember? Poor luddites forced to
work with C#. We'll need more than a buzzword phrase.

Of course, a quick bit of googling turns up a blog entry on how to
write/use monadic parser combinators in C# 3:

http://blogs.msdn.com/lukeh/archive/2007/08/19/monadic-parser-
combinators-using-c-3-0.aspx

As Luke says, it's inefficient etc - but doable.

However, the important thing in my view is that very few developers are
actually likely to need to write a parser. Maybe you do, and that's
fine - you may well be better off with F#. Now, perhaps you'll come up
with an example which is more widely applicable.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk
.

Relevant Pages

  • Re: Function minimization and random numbers
    ... Jon Skeet wrote: ... In what way does C# lack closures? ... Closures represent all functions but .NET delegates do not because .NET ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Function minimization and random numbers
    ... Well, .NET's type system makes the distinction, allowing conversions ... lacks closures. ... design but it culminated in F# rather than delegates. ... Are you claiming that the C# support for closures is useless? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Function minimization and random numbers
    ... Closures represent all functions but .NET delegates do not because .NET ... remove this artificial distinction. ... language features, that's fine, but if you want the features to be useful ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Function minimization and random numbers
    ... Jon Harrop wrote: ... Closures represent all functions but .NET delegates do not because .NET ... then you could say "C# supports first-class closures in the same ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Function minimization and random numbers
    ... Well, .NET's type system makes the distinction, allowing conversions ... Groovy supports overloaded method groups as closures, ... Consider a language that support integers but imposes a compile time ...
    (microsoft.public.dotnet.languages.csharp)