Daniel Earwicker

Daniel Earwicker danielearwi​cker I used to be language agnostic, now I'm language atheist

Comments

  • Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

    So does this mean that C# will be getting the equivalent of VB.NET's "When" keyword that can appear after a Catch, to control exception filtering?

    To briefly recap the issue, in C# today we can only filter exceptions by their exact type, or by their location in the type hierarchy (catching a base type). Unfortunately that isn't very useful because exceptions are not generally organized into useful type hierarchies. Deriving from ApplicationException to indicate "non-fatal" is now discouraged, for example, so in fact it should be expected that custom exception classes will all derive from Exception. Meanwhile, due to the lack of flexible exception filtering, the Exception Handling block of the Enterprise Library suggests catching the universal Exception base class, which directly contradicts the advice of the CLR program manager. The CLR team also suggest using VB.NET (or hand-written IL) to get access to "Catch/When" functionality from languages that don't have it such as C#.

  • Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming

    I love the way Erik says "Func" at about 10 minutes into the video. It reminds me of the classic "Rock Me Amadeus" by Falco!
  • Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming

    Yes, I saw that Hoare quote. That's the same conclusion I get to in that blog post, i.e. "It's not immediately obvious that it is [a bind function], because a Bind function talks to its caller in terms of values wrapped in the monad, but deals in "naked" values with the function passed to it. But IfNotNull uses ordinary reference variables in both situations. This is because there is a feature missing from C#. It ought to be possible to somehow tag a reference variable to say that it is definitely not null."

    In Spec# they used MyRefType! (exclamation suffix) to mean non-nullable; so the default is wrong but they were aiming at backward compatibility with C#, so they had to go that way. And then they would just look for an if (myVar != null) and silently make myVar non-nullable within the truth block.

    It looks like the closest we'll get to this in real C# is the Code Contracts library in CLR 4.0, but I really wish non-nullable was the default. Unfortunately it complicates the syntax in some areas (where should non-nullable instance fields in a class be initialized?) but it would surely have been worth it, as Hoare says.
  • Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming

    Given that reference variables can already be null or else point to something useful, don't they already have what is needed to represent the maybe monad? All that's lacking is the convenience of bind. An extension method can act as the bind operation and that's all you need, isn't it? Or have I missed something (I'm relatively new to Haskell!)

  • Expert to Expert: Erik Meijer and Anders Hejlsberg - The Future of C#

    Steve, I want the same thing, an extensible language. It's a real shame that the "syntactic sugar" (anything that can be specified in terms of other language features: the using statement, the Linq queries) was not built using a macro-like system that user could also take advantage of.

    You may be interested in the answer I got to this question.


  • Expert to Expert: Erik Meijer and Anders Hejlsberg - The Future of C#

    Enumerable.Empty is already there.
  • Jeffrey Richter and his Async​Enumerator

    Here's what I mean:

    http://incrediblejourneysintotheknown.blogspot.com/2008/12/asynchronous-sockets-with-yield-return.html

    Would be very interested to hear what Jeffrey thinks about it!
  • Jeffrey Richter and his Async​Enumerator

    Couldn't the function use yield return to hand back a lambda, and the lambda would contain the asynchronous call(s) to fire off?

    The calls could be made on an interface that wraps the socket and hides the details of managing the asynchronous nature of the call altogether.

    Hmm... this sounds like a good idea... I'll whip up something to demonstrate what I mean more clearly.
  • Brian Beckman: The Zen of Stateless State - The State Monad - Part 1

    I see - so Haskell says "trust me, this won't last" and Haskell is undoubtedly correct!

  • Brian Beckman: The Zen of Stateless State - The State Monad - Part 1

    I have a question. I had assumed that the definition of "bad" would be "a function that has side effects". But Brian gives the key definition as of a mathematical function, which is one that returns the same value given the same arguments. This is much neater because it means that you don't have to decide what "side effect" means (could mean a lot of things). But then I realised that this means that a mathematical function CAN have side effects! It just mustn't allow anything to affect what IT returns for a given set of arguments - but it is okay for it to affect what other functions will return. Those other functions would not be mathematical, because they reveal the side effects. So a mathematical function doesn't reveal side effects via its return - this says nothing about causing them.

    So my question is, as long as "printf" returns the same value for a given argument, what does it matter if it has the side effect of printing text out to the console? Why can't I add it to my program harmlessly? Previously I was using all mathematical functions, now I'm adding a printf call somewhere, that's also a mathematical function, so nothing has changed.

    (Or can I deduce from this that haskell's equivalent of printf returns a new modified instance of the console every time you call it...? Semi-serious question!)

  • Anders Hejlsberg and Guy Steele: Concurrency and Language Design

    That point about a base language that can support different syntaxes though library-like extensions - surely that has to be the way to go, in the long term?

    We already have an ever-growing range of APIs in the CLR to let us dynamically compile code snippets into executables. The C# and VB compilers are "libraries" in that sense. They need to be reusable in different contexts, e.g. partial compilation for IDE intellisense as well as the "real" compilation process. And so why not implement those two languages as AST processors on the same general compilation engine. And then introduce a way to let you switch syntax libraries in the middle of a file, or in an expression.