Dynamic Method Signatures

Topics: C# Language Design
Oct 9, 2014 at 3:29 PM
I would like C# to add dynamic signatures for a method call. Whats a dynamic signature? The ability to define a syntax that creates a method. A dynamic signature would allow for a text string to be converted to a method name and not dependent on the format of C#'s fixed methodname(parm,parm,parm);. It would also allow for code that generates a method signature. So how does the compiler recognize a dynamic method signature? If its not a language keyword or currently defined method name then its a dynamic signature. Dynamic signatures could be done at compile time or execution time. I know there is more to this but you language designers can handle it. Dynamic signatures would allow for application dependent languages.
Oct 9, 2014 at 3:38 PM
Edited Oct 9, 2014 at 3:38 PM
Oravendi wrote:
If its not a language keyword or currently defined method name then its a dynamic signature.
Actually, I'm pretty sure that's called a "syntax error".
Oct 9, 2014 at 3:44 PM
Your correct I am proposing a change to the design of the language.
Oct 9, 2014 at 3:53 PM
You're proposing a language that treats all mistakes as a particular construct.
Oct 9, 2014 at 4:36 PM
You can think of a dynamic signature method as a method that has a variable syntax interface format dependent on a prior definition. If the text string that is encountered in the program does not conform to one of the dynamic signature method definitions than yes its a syntax error otherwise it creates a method according to the dynamic methods definition. You might think of these as macros however a dynamic signature method would convert only to a method name with its signature, the methods interface, and not directly to program text. I know by mentioning macros I have probably lost this functionality for most designers however a compiler is fundamentally a generator, a generator that may be changed. A generator needs to conform to application rules and not to some white room self interest. By exposing the compilers API it would seem that Rosyln may be able to do this anyway.
Oct 9, 2014 at 5:18 PM
Can you show us some code for us to understand how it would be used?
Oct 9, 2014 at 6:37 PM
I am looking for a more user definable syntax. This is a crude example.

namespace SampleProg
{
using System;
using System.Data;
using System.Collections;
using System.Collections.Generic;
using System.Data.Common;
using System.Drawing;
using System.IO;
using System.Linq;

class Program
{
static void Main(string[] args)
{
bool result = false;
    result = Input 8 isGreaterthan 2;
    result = Input 8 isLessThan 2;
}
}


public static void DynamicSignature(Input)
{
ScanArgs  datatype()=D1 keyword()=K1 datatype()=D2;

if((D1 == typeof(int) & (K1 == "isGreaterThan") & (D2 == typeof(int))
    IsInputGT(D1,D2);
else if((D1 == typeof(int) & (K1 == "isLessThan") & (D2 == typeof(int))
    IsInputLT(D1,D2);
    else
     IssueSyntaxError("Error stuff");
}

public static bool isInputGT(int p1, int p2)
{
If (p1>p2)
{
    Console.PrintLine(p1 + "is greater than " + p2);
    return true;
}
else
{
    Console.PrintLine(p1 + "is not greater than " + p2);
    return false;
}
}

public static bool isInputLT(int p1, int p2)
{
If (p1<p2)
{
    Console.PrintLine(p1 + "is less than " + p2);
    return true;
}
else
{
    Console.PrintLine(p1 + "is not less than " + p2);
    return false;
}
}


}
}
Oct 9, 2014 at 8:15 PM
Instead of the ScanArgs syntax I used above, I'd like to see a select or case like syntax.
In this example if their are no arguments then noInput() is called. The |> is "If then". Each leg of
the tree ends with return methodname;
Each datatype is named so the programmer can reference the scanned information if needed.
I have changed this example for the "isLessThan" case to a hard coded 3.
If the user input does not follow the syntax tree then the compiler issues an error with the point of failure information.
Instead of a datatype(somedatatype) it would be interesting if a regular expression was defined.

public static void DynamicSignature(Input)
{
ScanSignature 
    {
        notype();
            return noInput();
        datatype(int)=D1 
        |> text("isGreaterThan")=K1
            |> datatype(int)=D2  
                return isInputGT(D1,D2);
        |> text("isLessThan")=K1
            return isInputLT(D1,3);
    }
    IssueError("Error stuff");
}
Oct 9, 2014 at 8:56 PM
So you want the means to be able to basically define a new language within the language through constructs defined in the language to be processed during the same compilation phase? What possible use-case scenario does this have? What are you attempting to solve that C# cannot solve today, other than wanting something that isn't remotely legal C# syntax?

If you're looking to define new methods off of an existing object you have existing facilities to do so. You have extension methods, and you have dynamic dispatch. The former would require defining the specific method signatures up front but the second is capable of being able to interpret the nature of the call site at runtime, which is closer to what I think you're looking to accomplish.

But as for the syntax x = y method arg1 arg2 you can pretty much guarantee that it's a non-starter.
Oct 9, 2014 at 10:01 PM
C# has changed over the years so I don't know which C# your happy with. Why extend any language? Why have generics or templates? Why is Rosyln exposing compiler APIs? Why is it that Native Dot Net exists? Most things can be done in most languages already. For me software is about ease of use. The easier it is to use the less time it takes to implement something. I like to write utility programs with simple APIs.
Oct 9, 2014 at 10:13 PM
It looks like you're after one of:

(a) Hygienic macros, which I'd quite like to have too;
(b) F#-style discriminated unions and other DSL-ish syntactic chicanery, which F# does really well;
(c) some kind of Backus-Naur Form grammar built right into an existing language, which is just madness;
or (d) something vague and esoteric, which you're having trouble explaining.
Oct 9, 2014 at 10:32 PM
A form of macro is probably the best description. I have considered writing a generator that dynamically calls the C# compiler. I could then do what ever it is that I wanted and will probably do that. If compiler syntax does not exist to make things easier than what is it doing? The day that C# generates native code will be a great one. Lets hope, thanks for being kind.
Oct 9, 2014 at 11:13 PM
Perhaps you should take a look at Nemerle, which is basically C# with some of the stuff you're seeking.
Oct 10, 2014 at 1:02 AM
Oravendi wrote:
C# has changed over the years so I don't know which C# your happy with. Why extend any language? Why have generics or templates? Why is Rosyln exposing compiler APIs? Why is it that Native Dot Net exists? Most things can be done in most languages already. For me software is about ease of use. The easier it is to use the less time it takes to implement something. I like to write utility programs with simple APIs.
To quote Lucian on the subject of language features:

lwischik wrote:
From my experience with past language features, the best way to achieve acceptance is
  1. Compelling evidence that the feature solves a real end-user need far better than any workaround. This is the bit that most people don't focus hard enough on. At the language design meetings, if we haven't seen something as a real problem in our own coding, or haven't seen comments from the public that persuade us that it's an actual real concrete problem, or haven't seen feedback on uservoice or from audiences at talks, then we'll often say "no".
  2. Survey of related problems that might be solved by a more general mechanism, so as to decide whether it's better to use a general mechanism or a specific one for this particular need.
  3. Survey of how the problem is solved in other languages, either languages used in industry or prototype languages that come from academia.
  4. A working prototype, because the act of writing the prototype invariably uncovers language design issues that no one had even thought of before. Also to uncover downstream IDE work that will have to be done.
  5. A working prototype, so people can play with it for real and see how it works.
  6. Review by some of the "test geniuses", the people who know ever last corner of the language and every oddity.
You started with a vague solution without even describing a problem. Even if the goal is to realize some form of metaprogramming you'd have to target specific use cases that show a compelling need for the enhancement. Languages definitely should evolve but their evolution should be extremely conservative and guarded.

C# is not a meta-programming language. It was never meant to be one. Macros were known and discussed during its initial design and they were rejected as being a source of confusion. Even in a much more limited sense custom operators were discussed and similarly rejected for the same reasons. The C# team seems to have no interest in tackling meta-programming even in exceedingly simple cases like aspect-oriented programming. To allow for redefinition of its basic grammar would be an exceedingly massive break from the language's tradition and charter and to allow programs to define themselves entirely with a turing-complete language within a language is just, well, let's just say that I think that you're barking up the wrong tree.

If you want a language with meta-programming and macro support you should probably check our Nemerle, or Boo if that still exists.
Oct 10, 2014 at 7:43 PM
Thanks everyone for your input on macros and meta-programming. As a footnote to this discussion I would like to offer from the ".NET Compiler Platform ("Roslyn") Overview" this statement from paragraph three:

" The transition to compilers as platforms dramatically lowers the barrier to entry for creating code focused tools and applications. It creates many opportunities for innovation in areas such as meta-programming, code generation and transformation, interactive use of the C# and VB languages, and embedding of C# and VB in domain specific languages.".

I thought perhaps the times were changing. For some folks, maybe not. Thanks again.