We Keep Coding

Trouble Converting Lambda Expression to Delegate Because of "some return types"

I'm writing a Linked List program in C# because I want to test how I feel about the language and I'm running into some serious difficulty. I'm trying to implement a Map method that functions like a Haskell map function (code below for both). However, I'm getting the error messages:
main.cs(43,66): error CS0029: Cannot implicitly convert type `void' to `MainClass.LinkedList<U>'
main.cs(43,33): error CS1662: Cannot convert `lambda expression' to delegate type `System.Func<MainClass.LinkedList<U>>' because some of the return types in the block are not implicitly convertible to the delegate return type
The relevant code in question:
Ideal Haskell code:
map :: [a] -> (a -> b) -> [b]
map (x:[]) f = (f x) : []
map (x:xs) f = (f x) : (map xs f)
C# code:
public class LinkedList<T> where T: class
{
public T first;
public LinkedList<T> rest;
public LinkedList(T x) {this.first = x;}
public void Join(LinkedList<T> xs)
{
Do(this.rest, ()=>this.rest.Join(xs), ()=>Assign(ref this.rest, xs));
}
public LinkedList<U> Map<U>(Func<T, U> f) where U: class
{
return DoR(this.rest, ()=>new LinkedList<U>(f(this.first)).Join(this.rest.Map(f)), ()=>new LinkedList<U>(f(this.first)));
}
public static void Assign<T>(ref T a, T b)
{
a = b;
}
public static U DoR<T, U>(T x, Func<U> f, Func<U> g)
{
if (x!=null) {return f();}
else {return g();}
}
public static void Do<T>(T x, Action f, Action g)
{
if (x != null) {f();}
else {g();}
}
While Assign, DoR (short for Do and Return), and Do seem like they're "code smell", they're what I came up with for trying to not write
if (x != null) {f();}
else {g();}
type statements (I'm used to patternmatching). If anybody has any better ideas, I'd love to know them, but mostly I'm concerned with the highlighted problem.

Starting with your immediate problem: the basic issue here is that you're mixing and matching lambda expressions that have either void return type or an actual return type. This can be addressed by changing your Join() method so that it returns the list used to call Join():
public LinkedList<T> Join(LinkedList<T> xs)
{
Do(this.rest, () => this.rest.Join(xs), () => Assign(ref this.rest, xs));
return this;
}
An alternative way would be to have a statement body lambda in the Map<U>() method that saves the new list to a variable and then returns that. But that adds a lot more code than just changing the Join() method, so it seems less preferable.
That said, you seem to be abusing C# a bit here. Just as when writing code in a functional language, one should really make an effort to write real functional code, in the manner idiomatic to that language, so too should one make an effort when writing C# code to write real imperative code, in the manner idiomatic to C#.
Yes, C# has some functional-like features in it, but they don't generally have the same power as the features found in real functional languages, and they are intended to allow C# programmers to get the low-hanging fruit of functional styles of code without having to switch languages. One particular thing also to be aware of is that lambda expressions generate a lot more code than normal C# imperative code.
Sticking to more idiomatic C# code, the data structure you're implementing above can be written much more concisely, and in a manner that creates much more efficient code. That would look something like this:
class LinkedList<T>
{
public T first;
public LinkedList<T> rest;
public LinkedList(T x) { first = x; }
public void Join(LinkedList<T> xs)
{
if (rest != null) rest.Join(xs);
else rest = xs;
}
public LinkedList<U> Map<U>(Func<T, U> f) where U : class
{
LinkedList<U> result = new LinkedList<U>(f(first));
if (rest != null) result.Join(rest.Map(f));
return result;
}
}
(For what it's worth, I don't see the point of the generic type constraint on your Map<U>() method. Why restrict it like that?)
Now, all that said, it seems to me that if you do want a functional-style linked-list implementation in C#, it would make sense to make it an immutable list. I'm not familiar with Haskell, but from my limited use of functional languages generally, I have the impression that immutability is a common feature in functional language data types, if not enforced 100% (e.g. XSL). So if trying to reimplement functional language constructs in C#, why not follow that paradigm?
See, for example, Eric Lippert's answer in Efficient implementation of immutable (double) LinkedList. Or his excellent series of articles on immutability in C# (you can start here: Immutability in C# Part One: Kinds of Immutability), where you can get ideas for how to create various immutable collection types.
In browsing Stack Overflow for related posts, I found several that, while not directly applicable to your question, may still be of interest (I know I found them very interesting):
how can I create a truly immutable doubly linked list in C#?
Immutable or not immutable?
Doubly Linked List in a Purely Functional Programming Language
Why does the same algorithm work in Scala much slower than in C#? And how to make it faster?
Converting C# code to F# (if statement)
I like that last one mainly for the way that in both the presentation of the question itself and the replies (answers and comments) help illustrate well why it's so important to avoid trying to just transliterate from one language to another, and instead to really try to become familiar with the way a language is designed to be used, and how common data structures and algorithms are represented in a given language, idiomatically.
Addendum:
Inspired by Eric Lippert's rough draft of an immutable list type, I wrote a different version that includes the Join() method, as well as the ability to add elements at the front and end of the list:
abstract class ImmutableList<T> : IEnumerable<T>
{
public static readonly ImmutableList<T> Empty = new EmptyList();
public abstract IEnumerator<T> GetEnumerator();
public abstract ImmutableList<T> AddLast(T t);
public abstract ImmutableList<T> InsertFirst(T t);
public ImmutableList<T> Join(ImmutableList<T> tail)
{
return new List(this, tail);
}
IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
class EmptyList : ImmutableList<T>
{
public override ImmutableList<T> AddLast(T t)
{
return new LeafList(t);
}
public override IEnumerator<T> GetEnumerator()
{
yield break;
}
public override ImmutableList<T> InsertFirst(T t)
{
return AddLast(t);
}
}
abstract class NonEmptyList : ImmutableList<T>
{
public override ImmutableList<T> AddLast(T t)
{
return new List(this, new LeafList(t));
}
public override ImmutableList<T> InsertFirst(T t)
{
return new List(new LeafList(t), this);
}
}
class LeafList : NonEmptyList
{
private readonly T _value;
public LeafList(T t)
{
_value = t;
}
public override IEnumerator<T> GetEnumerator()
{
yield return _value;
}
}
class List : NonEmptyList
{
private readonly ImmutableList<T> _head;
private readonly ImmutableList<T> _tail;
public List(ImmutableList<T> head, ImmutableList<T> tail)
{
_head = head;
_tail = tail;
}
public override IEnumerator<T> GetEnumerator()
{
return _head.Concat(_tail).GetEnumerator();
}
}
}
The public API is a little different from Eric's. You enumerate it to access the elements. The implementation is different as well; using a binary tree was how I enabled the Join() method.
Note that with the interface IEnumerable<T> implemented, one way to implement the Map<U>() method is to not do it at all and instead just use the built-in Enumerable.Select():
ImmutableList<T> list = ...; // whatever your list is
Func<T, U> map = ...; // whatever your projection is
IEnumerable<U> mapped = list.Select(map);
As long as the map function is relatively inexpensive, that would work fine. Any time mapped is enumerated, it will re-enumerate list, applying the map function. The mapped enumeration remains immutable, because it's based on the immutable list object.
There are probably other ways to do it (for that matter, I know of at least one other), but the above is what made the most sense to be conceptually.

Concise, fast singleton subclasses

I'm writing, in C#, an interpreter for a dynamic language, and implementing primitive functions as an abstract class Primitive with a virtual Apply method, where each actual primitive function will be a subclass that overrides Apply.
(An alternative would be to only have the class Primitive and store a function pointer for Apply. However, making it a virtual method seems likely to be slightly faster, and this code will be run very frequently, so a small speedup is worth having.)
Obviously I could go ahead and create a full-blown class file for each primitive function, but I can't help feeling there ought to be a slightly more concise way of doing things than creating dozens of tiny class files.
In Java I'd use the anonymous subclass syntax to create and instantiate a subclass all in one expression, but I don't think C# has an exact counterpart.
What is the best way of doing this in C#?

Firstly, I wouldn't assume that a virtual method call will be faster than a delegate. Maybe it will, maybe it won't - but if performance is really that important to you, you should measure that. It would be really simple to code this using lambda expressions, particularly if all you're trying to represent is a function:
public static readonly Func<int, int> Addition = (x, y) => x + y;
public static readonly Func<int, int> Subtraction = (x, y) => x - y;
// etc
(I'm just guessing at the sorts of operation here, as we don't know the details.)
There's no particularly tiny syntax for subclasses in C#, but for semi-singletons like this
I find nested classes work well... similar to Java enums:
public abstract class Primitive
{
public static readonly Primitive Addition = new AdditionPrimitive();
public static readonly Primitive Subtraction = new SubtractionPrimitive();
// Prevent outside instantiation
private Primitive()
{
}
public abstract int Apply(int x, int y);
// Anything else you want
private class AdditionPrimitive : Primitive
{
public override int Apply(int x, int y)
{
return x + y;
}
}
private class SubtractionPrimitive : Primitive
{
public override int Apply(int x, int y)
{
return x - y;
}
}
}

What is the best approach to implementing monads in C#

What are the best approaches to implementing monads in C#? Are there particular implementation-strategies or is every monad differently implemented from the other?

To answer the question instead of just commenting on it, Linq is probably the foremost method of performing monadic transformations in C#. A Linq method chain is nothing more than a lazily-evaluated, ordered set of list-processing operations.
Linq, of course, is not rocket science; more than your average college-level programming course, but still. It's a series of extension methods that each produce a placeholder enumerable (the monad) containing the logic they should perform, and a reference to their source of data (which can be another monadic encapsulation). You can, and many do, add additional extensions to the basic Linq library to fill holes in the functionality or perform custom actions that meet specific needs.
You can also create your own monadic method chain frameworks, to do practically anything. Pretty much any framework or library described as having a "fluent" coding interface is a monad-based library. There are fluent unit test asserters, fluent ORM configurations, even fluent domain-UI mapping extensions.
Implementing a monadic library in C# is usually done using a static class and static methods, which make use of one or more monadic types which are inaccessible from outside their intended usage. For instance, here is a basic monadic library that performs integer addition and subtraction:
public static class MonadicArithmetic
{
public static Monad Take(int input) { return new Monad(input); }
public class Monad
{
int theValue;
internal Monad(int input) { theValue = input; }
public Monad Add(int input){ return new Monad(theValue + input); }
public Monad Subtract(int input){ return new Monad(theValue - result); }
public int Value { get { return theValue; } }
}
}
...
//usage
var result = MonadicArithmetic.Take(1).Add(2).Subtract(1).Value; //2
Obviously this is very basic, and all operations are performed "eagerly". If those operations were complex, this may not be optimal, so instead, let's perform them "lazily":
public static class MonadicArithmetic
{
public static Monad Take(int input) { return new Monad(input); }
public class Monad
{
//Change the "value keeper" into a Func that will return the value;
Func<int> theValue;
//the constructor now turns the input value into a lambda
internal Monad(int input) { theValue = ()=>input; }
//and another constructor is added for intra-class use that takes a lambda
private Monad(Func<int> input) { theValue = input; }
//And now the methods will create new lambdas that call the existing lambdas
public Monad Add(int input){ return new Monad(()=>theValue() + input); }
public Monad Subtract(int input){ return new Monad(()=>theValue() - input); }
//Finally, our Value getter at the end will evaluate the lambda, unwrapping all the nested calls
public int Value { get { return theValue(); } }
}
}
Same usage, except no operations will be performed until a concrete Value is requested by consuming code:
//Each call just adds a shell to the nested lambdas
var operation = MonadicArithmetic.Take(1).Add(2).Subtract(1);
...
//HERE's the payoff; the result is not evaluated till the call to Value_get() behind the scenes of this assignment.
var result = operation.Value;
However, there's a problem with this. The methods simply take the input values, and reference them in a lambda. The problem is that the values' scope is dependent on the containing method (meaning they don't live long enough for the lambda to be evaluated). When the Value() getter is called, the lambda will be evaluated, and all of these out-of-scope variables will be referenced. Instead, we should persist the values in something that will live at least as long as the lambdas do. The monad is the obvious option. Here is a probable solution:
public static class MonadicArithmetic
{
public static Monad Take(int input) { return new Monad(input); }
public class Monad
{
//Our value keeper is now a pure function that requires no external closures
Func<Func<int>, int, int> operation;
//and we add two new private fields;
//a hook to a lambda that will give us the result of all previous operations,
Func<int> source;
//... and the value for the current operation.
private int addend;
//our constructor now takes the value, stores it, and creates a simple lambda
internal Monad(int input) { addend = input; operation = ()=>addend; }
//and our private constructor now builds a new Monad from scratch
private Monad(Func<int> prevOp, Func<Func<int>, int, int> currOp, int input)
{
source = prevOp,
operation = currOp,
addend = input;
}
//The methods will create new Monads that take the current Monad's value getter,
//keeping the current Monad in memory.
public Monad Add(int input)
{
return new Monad(this.Result, (f,i)=>f()+i, input);
}
public Monad Subtract(int input)
{
return new Monad(this.Result, (f,i)=>f()-i, input);
}
//And we change our property to a method, so it can also
//be used internally as a delegate
public int Result() { return operation(source, addend); }
}
}
//usage
var operations = MonadicArithmetic.Take(1).Add(3).Subtract(2);
//There are now 3 Monads in memory, each holding a hook to the previous Monad,
//the current addend, and a function to produce the result...
...
//so that here, all the necessary pieces are still available.
var result = operations.Result();
This is the basic pattern for a monadic library. The static method that starts the whole thing can be an extension method, which is the style Linq uses. The root of the method chain becomes the first value:
//using an "identity function" to convert to a monad
var operations = 1.AsMonad().Add(2).Subtract(3);
//performing the conversion implicitly from an overload of Add()
var operations = 1.Add(2).Subtract(3);
Linq for objects is particularly elegant in that its libraries are extension methods that take an IEnumerable and return an IEnumerable, so the conversion process is handled without any overloading or explicit method calls. However, IQueryable objects, which hide translatable expression trees, ARE a new idea in .NET 3.5, and you DO have to explicitly convert a collection to an IQueryable, via the AsQueryable() method.

overload operator = in C#. How can i accept other types?

So a friend was telling me how a game was hacked and how the technique worked. He then asked whats the best way to prevent that kind of attack. The most straight forward way i knew was to A) the shuffle the bits of important value B) hash the values and compare them every time (an int that holds the score or money is likely to be checked rarely).
Then i tried the implementation in C#, i couldnt overload the = operator. How can i do this?
ex code.
class EncryptVal <T>
{
T v;
public T operator = (T v2)
{
//shuffle bits
}
public T operator ()()
{
//return unshuffle bits
}
}

You're looking for the implicit and explicit operator, rather than saying =. This allows you to define how things will work when cast implicitly (ie, just an assignment) and explicitly (ie, there's a casting operator).
public static implicit operator Type1(Type2 p) {}
public static explicit operator Type1(Type2 p) {}

You can encapsulate the value in the class and overload the implicit conversions to and from the class:
public class EncryptVal<T> {
private T _value;
private EncryptVal(T value) {
_value = value;
}
public static implicit operator EncryptVal<T>(T value) {
//shuffle bits
return new EncryptVal<T>(value);
}
public static implicit operator T(EncryptVal<T> value) {
//unshuffle bits
return value._value;
}
}
Usage:
// implicit conversion from int
EncryptVal<int> e = 42;
// implicit conversion to int
int i = e;

You are not allowed to overload the assignment operator in C#. Here's the MSDN documentation on it.
You'll have to create your own function for this behavior.

I assume that you come from C++ where it is very common to write classes that are used like primitive data types. In C# you do things more explicitly.
I would write it as a property or as two methods, eg:
class EncryptVal <T>
{
T v;
public T Value
{
get
{
//return unshuffle bits
}
set
{
//shuffle bits
}
}
}

Dont use = for setting the value. You cant overload assignment.
What you can do is hide it behind a property.
int _encyptedValue;
Public int myInt
{
get
{
return Decrypt(_encryptedValue);
}
set
{
_encryptedValue = Encrypt(value);
}
}
You get to chosse your decryption/encryption

I would go the for implicit/explicit operator overloading for the implementation part.
Probably the explicit one since your conversion does heavy processing, and that it eventually could fail.
I would just add that shuffling bits seems to be only an obfuscation technic that will surely not last long if you have wishfull hackers interested in your game.
You probably need stronger cryptography to protect your data, but more context is needed.

Creating a Math library using Generics in C#

Is there any feasible way of using generics to create a Math library that does not depend on the base type chosen to store data?
In other words, let's assume I want to write a Fraction class. The fraction can be represented by two ints or two doubles or whatnot. The important thing is that the basic four arithmetic operations are well defined. So, I would like to be able to write Fraction<int> frac = new Fraction<int>(1,2) and/or Fraction<double> frac = new Fraction<double>(0.1, 1.0).
Unfortunately there is no interface representing the four basic operations (+,-,*,/). Has anybody found a workable, feasible way of implementing this?

Here is a way to abstract out the operators that is relatively painless.
abstract class MathProvider<T>
{
public abstract T Divide(T a, T b);
public abstract T Multiply(T a, T b);
public abstract T Add(T a, T b);
public abstract T Negate(T a);
public virtual T Subtract(T a, T b)
{
return Add(a, Negate(b));
}
}
class DoubleMathProvider : MathProvider<double>
{
public override double Divide(double a, double b)
{
return a / b;
}
public override double Multiply(double a, double b)
{
return a * b;
}
public override double Add(double a, double b)
{
return a + b;
}
public override double Negate(double a)
{
return -a;
}
}
class IntMathProvider : MathProvider<int>
{
public override int Divide(int a, int b)
{
return a / b;
}
public override int Multiply(int a, int b)
{
return a * b;
}
public override int Add(int a, int b)
{
return a + b;
}
public override int Negate(int a)
{
return -a;
}
}
class Fraction<T>
{
static MathProvider<T> _math;
// Notice this is a type constructor. It gets run the first time a
// variable of a specific type is declared for use.
// Having _math static reduces overhead.
static Fraction()
{
// This part of the code might be cleaner by once
// using reflection and finding all the implementors of
// MathProvider and assigning the instance by the one that
// matches T.
if (typeof(T) == typeof(double))
_math = new DoubleMathProvider() as MathProvider<T>;
else if (typeof(T) == typeof(int))
_math = new IntMathProvider() as MathProvider<T>;
// ... assign other options here.
if (_math == null)
throw new InvalidOperationException(
"Type " + typeof(T).ToString() + " is not supported by Fraction.");
}
// Immutable impementations are better.
public T Numerator { get; private set; }
public T Denominator { get; private set; }
public Fraction(T numerator, T denominator)
{
// We would want this to be reduced to simpilest terms.
// For that we would need GCD, abs, and remainder operations
// defined for each math provider.
Numerator = numerator;
Denominator = denominator;
}
public static Fraction<T> operator +(Fraction<T> a, Fraction<T> b)
{
return new Fraction<T>(
_math.Add(
_math.Multiply(a.Numerator, b.Denominator),
_math.Multiply(b.Numerator, a.Denominator)),
_math.Multiply(a.Denominator, b.Denominator));
}
public static Fraction<T> operator -(Fraction<T> a, Fraction<T> b)
{
return new Fraction<T>(
_math.Subtract(
_math.Multiply(a.Numerator, b.Denominator),
_math.Multiply(b.Numerator, a.Denominator)),
_math.Multiply(a.Denominator, b.Denominator));
}
public static Fraction<T> operator /(Fraction<T> a, Fraction<T> b)
{
return new Fraction<T>(
_math.Multiply(a.Numerator, b.Denominator),
_math.Multiply(a.Denominator, b.Numerator));
}
// ... other operators would follow.
}
If you fail to implement a type that you use, you will get a failure at runtime instead of at compile time (that is bad). The definition of the MathProvider<T> implementations is always going to be the same (also bad). I would suggest that you just avoid doing this in C# and use F# or some other language better suited to this level of abstraction.
Edit: Fixed definitions of add and subtract for Fraction<T>.
Another interesting and simple thing to do is implement a MathProvider that operates on an abstract syntax tree. This idea immediately points to doing things like automatic differentiation: http://conal.net/papers/beautiful-differentiation/

I believe this answers your question:
http://www.codeproject.com/KB/cs/genericnumerics.aspx

Here's a subtle problem that comes with generic types. Suppose an algorithm involves division, say Gaussian elimination to solve a system of equations. If you pass in integers, you'll get a wrong answer because you'll carry out integer division. But if you pass in double arguments that happen have integer values, you'll get the right answer.
The same thing happens with square roots, as in Cholesky factorization. Factoring an integer matrix will go wrong, whereas factoring a matrix of doubles that happen to have integer values will be fine.

First, your class should limit the generic parameter to primitives ( public class Fraction where T : struct, new() ).
Second, you'll probably need to create implicit cast overloads so you can handle casting from one type to another without the compiler crying.
Third, you can overload the four basic operators as well to make the interface more flexible when combining fractions of different types.
Lastly, you have to consider how you are handling arithmetic over and underflows. A good library is going to be extremely explicit in how it handles overflows; otherwise you cannot trust the outcome of operations of different fraction types.

The other approaches here will work, but they have a high performance impact over raw operators. I figured I would post this here for someone who needs the fastest, not the prettiest approach.
If you want to do generic math without paying a performance penalty, then this is, unfortunately, the way to do it:
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static T IncrementToMax(T value)
{
if (typeof(T) == typeof(char))
return (char)(object)value! < char.MaxValue ? (T)(object)(char)((char)(object)value + 1) : value;
if (typeof(T) == typeof(byte))
return (byte)(object)value! < byte.MaxValue ? (T)(object)(byte)((byte)(object)value + 1) : value;
// ...rest of the types
}
It looks horrific, I know, but using this method will produce code that runs as fast as possible. The JIT will optimize out all the casts and conditional branches.
You can read the explanation and some additional important details here: http://www.singulink.com/codeindex/post/generic-math-at-raw-operator-speed

.NET 7 introduces a new feature - generic math (read more here and here) which is based on addition of static abstract interface methods. This feature introduces a lot of interfaces which allow to generically abstract over number types and/or math operations:
class Fraction<T> :
IAdditionOperators<Fraction<T>, Fraction<T>, Fraction<T>>,
ISubtractionOperators<Fraction<T>, Fraction<T>, Fraction<T>>,
IDivisionOperators<Fraction<T>, Fraction<T>, Fraction<T>>
where T : INumber<T>
{
public T Numerator { get; }
public T Denominator { get; }
public Fraction(T numerator, T denominator)
{
Numerator = numerator;
Denominator = denominator;
}
public static Fraction<T> operator +(Fraction<T> left, Fraction<T> right) =>
new(left.Numerator * right.Denominator + right.Numerator * left.Denominator,
left.Denominator * right.Denominator);
public static Fraction<T> operator -(Fraction<T> left, Fraction<T> right) =>
new(left.Numerator * right.Denominator - right.Numerator * left.Denominator,
left.Denominator * right.Denominator);
public static Fraction<T> operator /(Fraction<T> left, Fraction<T> right) =>
new(left.Numerator * right.Denominator, left.Denominator * right.Numerator);
}