Untyped functions in static languages

Question

I'll be using Java in this post, but the following also applies to C#, and likely other languages.

We require that submissions must be a first-class function, or a full program to be valid. In Java, many users have started using untyped lambdas as their submission. The problem with untyped lambdas is that they have no meaning without their types.

For example, given a theoretical challenge of Add Two Numbers, in Java, a submission would look like:

(a,b) -> a + b

which seems relatively reasonable. However, the problem lies with the following solution:

(a,b) -> a.add(b)

The problem with the above statement is that we have absolutely no idea which function is getting called. The only way the above statement could ever work in code is if we say in the description that a and b are BigInteger.

To extend this problem further, lets say I'm answering a sorting challenge. You could submit:

list -> list.sortThis()

Now wait, sortThis() isn't a function on arrays, or on ArrayList, or anywhere in the JDK. I'd have you tell you that list is a MutableList from Eclipse Collections for you to ever use the code. Furthermore, if I did use that code, you don't need to import a MutableList. Java is able to deduce the types, no import needed.

We require the submissions be self-contained, but right now, these lambdas are not self-contained, because they require outside input to indicate the types.

How do we solve this problem?

Answer 1

TL;DR: Lambdas should not require their types.

---

I think that the lambdas shouldn't require types. A lambda does not need the type to be specified when you assign it to the function. For example, in C#:

Func<int, int, int> f = (a,b) => a + b;

Compiles just fine. In fact I didn't even know you could specify the type in the lambda before I saw this post.

Another reason to allow this is that these languages are never going to beat a golfing language and requiring types only increases the gap. As code compiles just fine without them, there is no need to add them in.

I don't buy the argument about not knowing what function is called. To solve it you can either a) Ask the author or b) Require people state what the anonymous function compiles to:

s=>s.Length

Compiles to a Func<string, int>.

Lastly, if we require types for the inputs it is only logical that we then have to require types for outputs. This makes no sense in the case of a lambda as there is no way to do this without showing what it compiles to. At that point it just becomes shorter to use a normal method and do away with lambdas on PPCG altogether.

Answer 2

Types should be included but not in the bytecount

The main argument is that a person wishing to use the lambda may not know the datatype just by looking at the function since it's implicitly set within the context of the lambda. This is a good argument for requiring that the datatype be specified in the answer... but this is code golf, people; if bytes aren't needed for a line of code to be valid, they're going to be omitted.

It seems like until recently people have been content with the untyped lambdas. This is likely because on PPCG there's almost always a rule where you can assume input is valid. Part of valid input includes the datatype in this example. The part that makes Java or C# different from Python or Javascript is that Java and C# are strongly typed. If you don't have the correct datatype, the code won't compile let alone run. In Python or Javascript you can call a function with any datatype you want... but it will likely error if you use one that's unintended.

Consider a javascript object a = {key: 'value'}. Suppose I expect this format for parameters to my function. In classic javascript fashion I'm able to invoke console.log(a.key); If my program relies on that functionality then it's going to error if you pass in 1.

> 1.key
Uncaught SyntaxError: Invalid or unexpected token

I would need to specify in my answer that input is expected to be in a certain format or datatype but that wouldn't affect my bytecount.

Answer 3

Java already allows contextual imports. So contextual information is allowed.

Take the two files:

A.java

import java.util.*;
class A {
  static List<String> list = Arrays.asList("foo");
}

B.java

// NO IMPORTS!!
class B {
  public static void main(String[] args) {
    System.out.println(A.list.get(0));
  }
}

Here, B depends on java.util.List, but java.util.List isn't declared in the imports.

One of my previous answer's one of my previous golfed answer showed that no imports are required in the context of a lambda. You can call it black magic, but it works. Types can be contextual in Java, and Lambda are no exception to this.

Here is the answer, retyped, for clarity of the example:

LookMaNoImports.java

class LookMaNoImports {
  static Main.F f = s -> // transform a Stream<Boolean>
    s.map(               // by applying its map method
      b ->               // which in turns transforms a boolean 
        !b               // by applying its negation.
    );
}

Main.java

import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class Main {
    interface F {
        Stream<Boolean> f(Stream<Boolean> s);
    }

    public static void main(String[] args) {
        F f=LookMaNoImports.f;

        test(f, new Boolean[]{true}, new Boolean[]{false});
        test(f, new Boolean[]{false}, new Boolean[]{true});
        test(f, new Boolean[]{true, false}, new Boolean[]{false, true});
        test(f, new Boolean[]{true, true}, new Boolean[]{false, false});
    }

    static void test(F f, Boolean[] param, Boolean[] expected) {
        List<Boolean> result = f.f(Arrays.stream(param)).collect(Collectors.toList());
        if (result.equals(Arrays.asList(expected))) {
            System.out.printf("%s: OK%n", Arrays.toString(param));
        } else {
            System.out.printf("%s: NOT OK, expected %s%n", Arrays.toString(param), Arrays.toString(expected));
        }
    }
}

Answer 4

Require types to be added if a method/function/operator cannot be deduced

This answer only applies to languages with manifest typing.

Java and C# both have the ability to define types in the definition:

(int a, int b) => a + b   // C#
(int a, int b) -> a + b   // Java

This gets immensely useful when dealing with objects:

(BigInteger a, BigInteger b) -> a.add(b)
(MutableList a) -> a.sortThis()

Furthermore, because the above two examples only involve a single function, you can shorten them to:

BigInteger::add    
MutableList::sortThis

Another acceptable format would be:

Function<MutableList, MutableList> f = a -> a.sortThis()

Even though the lambda itself does not contain the type, the method sortThis() can still be deduced.

In all of these examples, imports would still be required because the types BigInteger or MutableList are explicitly listed. The key here is that the submissions are self-contained; They contain all of the type information you need to run.