Support placeholders and selectable-overloads

[ikatyang]

Ideas

If TS cannot select the correct signature, why don't we select it ourselves?

If types are too hard to build manually, why don't we generate it programmatically?

Types

consider the following types for R.adjust(), it looks ugly but works perfectly in my testing.

type PH = {'@@functional/placeholder': true};
declare const __: PH;

// adjust.d.ts
type adjust = adjust_000;
type adjust_000 = {
  <T, U>(fn: (v: T) => U, index: number, array: T[]): adjust_111<T, U>;
  <T, U>(fn: (v: T) => U, _index: PH, array: T[]): adjust_101<T, U>;
  <T>(_fn: PH, index: number, array: T[]): adjust_011<T>;
  <T>(_fn: PH, _index: PH, array: T[]): adjust_001<T>;
  <T, U>(fn: (v: T) => U, index: number): adjust_110<T, U>;
  (_fn: PH, index: number): adjust_010;
  <X extends "111">(): <T, U>(fn: (v: T) => U, index: number, array: T[]) => adjust_111<T, U>;
  <X extends "101">(): <T, U>(fn: (v: T) => U, _index: PH, array: T[]) => adjust_101<T, U>;
  <X extends "011">(): <T>(_fn: PH, index: number, array: T[]) => adjust_011<T>;
  <X extends "001">(): <T>(_fn: PH, _index: PH, array: T[]) => adjust_001<T>;
  <X extends "11">(): <T, U>(fn: (v: T) => U, index: number) => adjust_110<T, U>;
  <X extends "01">(): (_fn: PH, index: number) => adjust_010;
  <X extends "1">(): <T, U>(fn: (v: T) => U) => adjust_100<T, U>;
  <T, U>(fn: (v: T) => U): adjust_100<T, U>;
};
type adjust_001<T> = {
  <U>(fn: (v: T) => U, index: number): adjust_111<T, U>;
  (_fn: PH, index: number): adjust_011<T>;
  <X extends "11">(): <U>(fn: (v: T) => U, index: number) => adjust_111<T, U>;
  <X extends "01">(): (_fn: PH, index: number) => adjust_011<T>;
  <X extends "1">(): <U>(fn: (v: T) => U) => adjust_101<T, U>;
  <U>(fn: (v: T) => U): adjust_101<T, U>;
};
type adjust_010 = {
  <T, U>(fn: (v: T) => U, array: T[]): adjust_111<T, U>;
  <T>(_fn: PH, array: T[]): adjust_011<T>;
  <X extends "11">(): <T, U>(fn: (v: T) => U, array: T[]) => adjust_111<T, U>;
  <X extends "01">(): <T>(_fn: PH, array: T[]) => adjust_011<T>;
  <X extends "1">(): <T, U>(fn: (v: T) => U) => adjust_110<T, U>;
  <T, U>(fn: (v: T) => U): adjust_110<T, U>;
};
type adjust_011<T> = {
  <U>(fn: (v: T) => U): adjust_111<T, U>;
};
type adjust_100<T, U> = {
  (index: number, array: T[]): adjust_111<T, U>;
  (_index: PH, array: T[]): adjust_101<T, U>;
  <X extends "11">(): (index: number, array: T[]) => adjust_111<T, U>;
  <X extends "01">(): (_index: PH, array: T[]) => adjust_101<T, U>;
  <X extends "1">(): (index: number) => adjust_110<T, U>;
  (index: number): adjust_110<T, U>;
};
type adjust_101<T, U> = {
  (index: number): adjust_111<T, U>;
};
type adjust_110<T, U> = {
  (array: T[]): adjust_111<T, U>;
};
type adjust_111<T, U> = (T | U)[];

Since curried function can return itself by calling with non-parameter, we can use generic to select one of those overloads.

If we want to choose one of the overloads in the signature, it just works fine. ( the "11" means choosing the one with 2 ("11".length) parameters and both parameter are not placeholder )

ps. I think something like "11" is easily to notice which case to use, but it can be changed into something else.

R.adjust<"11">() //=> <T, U>(fn: (v: T) => U, index: number) => adjust_110<T, U>;

and with placeholder ( the "01" means choosing the one with 2 ("01".length) parameters, the first parameter is a placeholder, and the last parameter is not a placeholder )

R.adjust(R.__, 1)<"01">() //=> <T>(_fn: PH, array: T[]) => adjust_011<T>

If there are many kinds of the function, like R.map() for array, functor, etc., we can create them one by one and mixed them with intersection ( & ):

type map_array = map_array_00;
type map_functor = map_functor_00;
type map = map_array & map_functor;

If TS cannot find the correct signature, we can do it ourselves, it just works fine with good looking.

(R.map as R.map_array)(blah, blah, ...)

Implementation

To implement this types, I wrote a dts DOM library dts-element, the following code will generate the above adjust.d.ts.

import * as dts from 'dts-element';

const name = 'adjust';
const placeholder = new dts.BasicType({name: 'PH'});

const generic_T = new dts.GenericType({name: 'T'});
const generic_U = new dts.GenericType({name: 'U'});

// <T, U>(fn: (v: T) => U, index: number, array: T[]) => (T | U)[]
const function_type = new dts.FunctionType({
  generics: [generic_T, generic_U],
  parameters: [
    new dts.Parameter({
      name: 'fn',
      type: new dts.FunctionType({
        parameters: [
          new dts.Parameter({name: 'v', type: generic_T}),
        ],
        return: generic_U,
      }),
    }),
    new dts.Parameter({name: 'index', type: dts.number_type}),
    new dts.Parameter({name: 'array', type: new dts.ArrayType({owned: generic_T})}),
  ],
  return: new dts.ArrayType({owned: new dts.UnionType({types: [generic_T, generic_U]})}),
});

const types = dts.create_curried_function_types({
  name,
  placeholder,
  type: function_type,
  selectable: true,
});
const document = new dts.Document({children: types});

console.log(document.emit());

• test-cases
• snapshots

I am new to functional programming and ramda, I may not consider something else, please correct me if I am wrong.

I think functional programming is a better way to write code and hope to build a full-supported ramda.d.ts, let me know if you need any help, I am happy to make this types better and better.

[KiaraGrouwstra]

Hey, thanks for making this thread.

You've touched upon both sources for typing variations per function: both actual variations (normally based on input types), and currying variations.

In that first category, your (R.map as R.map_array) example is pretty interesting -- you're right that with partial application TS has trouble selecting the right variation there, and if this is a way to solve that, then that sounds like a pretty welcome alternative to having to manually override the type otherwise.

I liked the idea of codegen to deal with currying as well, and though it wasn't fully finished, a current attempt at doing that did include code for adjust so far.
The first thing one would notice in your version is that your definition has ended up somewhat more convoluted than the current manual version.
My interpretation here is that this difference stems from the fact that your version is also able to deal with 0-parameter application, returning the function itself. Is that right?

Out of curiosity, would you mind commenting on the use-case / context where 0-param application became a point for you? I realize it's valid Ramda. That said, I do feel concerned about the utility vs. cost economics of this feature, both for the per-function code on our end (comparing the fragments required to generate the code), as well as for users (code without explicit flags still works, right?).

Overall, the topic you're bringing up is actually pretty interesting. I could, for example, imagine a different variation than you've mentioned so far: using e.g. R.map<'array'>()(fn)(arr), utilizing the "0-param application yields a free chance to select overload" idea you gave for currying.

On enabling 0-param application, I wonder if there may be an easier way, kind of like:

interface ZeroEnabled<F> { 
  () => F;
  F;
}

... or, well, any actually working simple-ish alternative in that fashion, whatever that might be...

[ikatyang]

usecase of selectable overloads

My interpretation here is that this difference stems from the fact that your version is also able to deal with 0-parameter application, returning the function itself. Is that right?

Yes, it will return itself but with the specified overload used only.

That said, I do feel concerned about the utility vs. cost economics of this feature, both for the per-function code on our end (comparing the fragments required to generate the code), as well as for users (code without explicit flags still works, right?).

So I put the selectable overloads before the last case, TS will select the last case while it cannot determine which to use, correct me if I am wrong.

type adjust_100<T, U> = {
  (index: number, array: T[]): adjust_111<T, U>;
  (_index: PH, array: T[]): adjust_101<T, U>;
  <X extends "11">(): (index: number, array: T[]) => adjust_111<T, U>;
  <X extends "01">(): (_index: PH, array: T[]) => adjust_101<T, U>;
  <X extends "1">(): (index: number) => adjust_110<T, U>; // before last case
  (index: number): adjust_110<T, U>; // TS will select the last case while cannot be determined
};

Actually, I have tried to build my own @ikatyang/types-ramda at the begining with just placeholders supported, but I had faced to a problem like:

declare function example<R>(fn: (...args: any[]) => R): R; 

while passing the curried function like adjust, it cannot pick up the overload I want to use.

example(R.adjust) //=> ???
example(R.adjust<"11">()) //=> predictable

So I started to create dts-element for generating the dts structurally.

---

readability for codegen vs manual

As you can see in the first comment, the following will generate the ugly types.

const types = dts.create_curried_function_types({
  name,
  placeholder,
  type: function_type,
  selectable: true,
});
const document = new dts.Document({children: types});
console.log(document.emit()); //=> type adjust_XXX ...

It is not just for generating curried types, it can generate all valid dts, the following will generate the original type

const type_declaration = new dts.TypeDeclaration({
  name,
  type: function_type,
});
const document = new dts.Document({children:[type_declaration]});
console.log(document.emit()); //=> type adjust = <T, U>(fn: (v: T) => U, index: number, array: T[]) => (T | U)[]

It is easily to switch between ugly-curried and original cases.

About ZeroEnabled

I thought that useless cases are invalid, like

• 0-param

  R.adjust()()()()()()()()(...)

• last-parameter-placeholder

  R.adjust(R.__)(R.__)(R.__)(R.__)(R.__)(...)

But I found that 0-param can be used to select the specified overload, which is awesome.
And I still thought 0-param is an invalid usecase, but for selecting overload is OK.

I think there is no easy way for ZeroEnabled, since the overload order is important in TS.

Edit

interface ZeroEnabled<F> { 
  (): F;
  F; // <--- invalid...
}

Edit
...the above usecase is invalid, generic type can not be used as InterfaceMember, 'F' is considered an identifier.
So it may not have easier way to do such things.

---

And also, the interface version with placeholder (also auto generated):

interface CurriedFunction3<T1, T2, T3, R> {
  (v1: T1, v2: T2, v3: T3): R;
  (v1: T1, _2: PH, v3: T3): CurriedFunction1<T2, R>;
  (_1: PH, v2: T2, v3: T3): CurriedFunction1<T1, R>;
  (_1: PH, _2: PH, v3: T3): CurriedFunction2<T1, T2, R>;
  (v1: T1, v2: T2): CurriedFunction1<T3, R>;
  (_1: PH, v2: T2): CurriedFunction2<T1, T3, R>;
  (v1: T1): CurriedFunction2<T2, T3, R>;
}

[KiaraGrouwstra]

I'm sorry, I finally understood the problem you're tackling is not 0-param calls, but Ramda placeholder (R.__), earlier requested in #120. At that time I'd also been hoping to tackle that on the level of the CurriedFunction interfaces, as you've suggested just now. For those, feel free to send a PR already, the version you showed looks good to me.
Perhaps put the placeholder versions above the normal versions though -- if T2 includes the type of PH (if it's an object or any), we'd wanna make sure it won't mistake the placeholder for a regular parameter.

That said, I do feel concerned about the utility vs. cost economics of this feature, both for:

• the per-function code on our end (comparing the fragments required to generate the code),

On second glance, I think the data structure you use for codegen isn't so difference from the one I'd added in scripts -- it looks more verbose, but I guess the idea is the same otherwise, so I guess those should be compatible. This should address the concern of verbosity for contributors to this repo.

• as well as for users (code without explicit flags still works, right?).

So I put the selectable overloads before the last case, TS will select the last case while it cannot determine which to use, correct me if I am wrong.

Yeah, that sounds correct. So that addresses my concern about UX -- thanks.

I'm starting to get where you're going about using generics over overloads using placeholder type, given you're not immediately passing parameters. I suppose in the use-case where parameters had been passed, one would probably want to handle placeholders with overloads with placeholder type, so that no generics would need to be manually specified.

I guess with my idea of putting variations e.g. array as options passed through generics as well, we'd stumble on a different question though, of how these two would interact. That is, in what order might one pass these? I suppose variations like array might no longer need to be decided at the end if one is flipping argument order as well, which sounds like the answer is "either 'first', or 'figure out by case, though it'll be complicated'".

If there are many kinds of the function, like R.map() for array, functor, etc., we can create them one by one and mixed them with intersection (&)

Complication: curried variants need to be mixed into one and the same interface, or TS would ignore all but the first one. I haven't tested your approach, but it's something to keep in mind here. This particular point was currently handled in my codegen in scripts.
If they can be mixed even when separate like this though, that'd be great -- makes it easier to get separate versions to pre-select by those as you suggested (be it by cast or by generic).

the above usecase is invalid, generic type can not be used as InterfaceMember

Yeah, I know, just tried to give the simplest version I could think of. But now I realize enabling 0-param application wasn't really your goal, just a means to pre-selecting placeholder variations for use in un-applied functions.

I'm initially under the impression unapplied placeholders seem a bit of a niche (compared to applying them right away); otherwise I'm under the impression there are no real blockers here though, so if we could combine the advantages of our codegen methods (low verbosity, dealing with placeholders / currying / mixing partially applied variations), then that would be great.

[ikatyang]

Perhaps put the placeholder versions above the normal versions though if T2 includes the type of PH (if it's an object or any), we'd wanna make sure it won't mistake the placeholder for a regular parameter.

Did you mean the following code?

interface CurriedFunction3<T1, T2, T3, R> {
  (v1: T1, _2: PH, v3: T3): CurriedFunction1<T2, R>;
  (_1: PH, v2: T2, v3: T3): CurriedFunction1<T1, R>;
  (_1: PH, _2: PH, v3: T3): CurriedFunction2<T1, T2, R>; // above the normal version
  (v1: T1, v2: T2, v3: T3): R;
  (_1: PH, v2: T2): CurriedFunction2<T1, T3, R>; // above the normal version
  (v1: T1, v2: T2): CurriedFunction1<T3, R>;
  (v1: T1): CurriedFunction2<T2, T3, R>;
}

If so, it would be a strange UX but will work perfectly with T2 === any since TS will select the first matched overload, you'll see the placeholder version first instead of the detailed one.

UX vs Correctness, I think correctness is better.

---

On second glance, I think the data structure you use for codegen isn't so difference from the one I'd added in scripts -- it looks more verbose, but I guess the idea is the same otherwise, so I guess those should be compatible.

My version is more verbose since I have to track the dependencies of the generic types.

for example

append: [
  ['T', 'U'],
  {
    el: 'U',
    list: 'List<T>',
  },
  '(T & U)[]'
]

It looks good, but how can I trace the dependencies of T and U ?

el ( uses U ) and list ( uses T ) can be different order, we cannot use something like returns.indexOf('T') to track it.

This should address the concern of verbosity for contributors to this repo.

I know, but UX vs Correctness again. Maybe we can link this issue as a reference?

EDIT: Sorry, I forgot the regex /\b${xxx}\b/, but I think my structure is better on using #clone(), #has(), #equal(), etc., and dts full-supported.

---

I guess with my idea of putting variations e.g. array as options passed through generics as well, we'd stumble on a different question though, of how these two would interact. That is, in what order might one pass these? I suppose variations like array might no longer need to be decided at the end if one is flipping argument order as well, which sounds like the answer is "either 'first', or 'figure out by case, though it'll be complicated'".

Sorry, I just forgot this case.

Since I can generate it manually, so I think it can be generated programmatically, I'll try it later.

manual:

type map_11_array<U> = U[];
type map_11_mappable<U> = Mappable<U>;
type map_10_array<T, U> = {
  (array: T[]): map_11_array<U>;
};
type map_10_mappable<T, U> = {
  (mappable: Mappable<T>): map_11_mappable<U>;
};
type map_10<T, U> = {
  (array: T[]): map_11_array<U>;
  <K extends 'array'>(): map_10_array<T, U>;
  <K extends 'mappable'>(): map_10_mappable<T, U>;
  (mappable: Mappable<T>): map_11_mappable<U>;
};
type map_01_array<T> = {
  <U>(fn: (v: T) => U): map_11_array<U>
};
type map_01_mappable<T> = {
  <U>(fn: (v: T) => U): map_11_mappable<U>
};
type map_00_array = {
  <T, U>(fn: (v: T) => U, array: T[]): map_11_array<U>;
  <T>(_fn: PH, array: T[]): map_01_array<T>;
  <X extends "11">(): <T, U>(fn: (v: T) => U, array: T[]) => map_11_array<U>;
  <X extends "01">(): <T>(_fn: PH, array: T[]) => map_01_array<T>;
  <X extends "1">(): <T, U>(fn: (v: T) => U) => map_10_array<T, U>
  <T, U>(fn: (v: T) => U): map_10_array<T, U>;
};
type map_00_mappable = {
  <T, U>(fn: (v: T) => U, mappable: Mappable<T>): map_11_mappable<U>;
  <T>(_fn: PH, mappable: Mappable<T>): map_01_mappable<T>;
  <X extends "11">(): <T, U>(fn: (v: T) => U, mappable: Mappable<T>) => map_11_mappable<U>;
  <X extends "01">(): <T>(_fn: PH, mappable: Mappable<T>) => map_01_mappable<T>;
  <X extends "1">(): <T, U>(fn: (v: T) => U) => map_10_mappable<T, U>;
  <T, U>(fn: (v: T) => U): map_10_mappable<T, U>;
};
type map_00 = {
  <T, U>(fn: (v: T) => U, array: T[]): map_11_array<U>;
  <T, U>(fn: (v: T) => U, mappable: Mappable<T>): map_11_mappable<U>;
  <T>(_fn: PH, array: T[]): map_01_array<T>;
  <T>(_fn: PH, mappable: Mappable<T>): map_01_mappable<T>;
  <K extends 'array', X extends "11">(): <T, U>(fn: (v: T) => U, array: T[]) => map_11_array<U>;
  <K extends 'array', X extends "01">(): <T>(_fn: PH, array: T[]) => map_01_array<T>;
  <K extends 'array', X extends "1">(): <T, U>(fn: (v: T) => U) => map_10_array<T, U>
  <K extends 'array'>(): map_00_array;
  <K extends 'mappable', X extends "11">(): <T, U>(fn: (v: T) => U, mappable: Mappable<T>) => map_11_mappable<U>;
  <K extends 'mappable', X extends "01">(): <T>(_fn: PH, mappable: Mappable<T>) => map_01_mappable<T>;
  <K extends 'mappable', X extends "1">(): <T, U>(fn: (v: T) => U) => map_10_mappable<T, U>;
  <K extends 'mappable'>(): map_00_mappable;
  <T, U>(fn: (v: T) => U): map_10<T, U>;
};

---

Complication: curried variants need to be mixed into one and the same interface, or TS would ignore all but the first one. I haven't tested your approach, but it's something to keep in mind here. This particular point was currently handled in my codegen in scripts. If they can be mixed even when separate like this though, that'd be great -- makes it easier to get separate versions to pre-select by those as you suggested (be it by cast or by generic).

It seems it just mixin the first layer, for example:

type A = {
  (): {
    (): string;
  };
  (): number;
};

type B = {
  (): {
    (): symbol;
  };
  (): boolean;
};

type C = A & B;

declare const c: C;

c()() //=> string

[KiaraGrouwstra]

CurriedFunction

Did you mean the following code?

Yeah, both CurriedFunction and the actual typings, yeah. Like, in this part the PH version should go first too in case of any / whatever:

  <T, U>(fn: (v: T) => U, index: number, array: T[]): adjust_111<T, U>;
  <T, U>(fn: (v: T) => U, _index: PH, array: T[]): adjust_101<T, U>;

how can I trace the dependencies of T and U?

I ran into exactly that in the current implementation. I just check when we get to new parameters (using a non-placeholder, of course) -- if these contain (= case-sensitive full-word regex match) one of the generics not used thus far, then now it's used, so should be added.

It seems it just mixin the first layer

Hm, yeah, looks like merging typings using just & wouldn't get what we'd need for TS. That said, we're currently already able to generate both mixed and separate versions (mixed versions are generated when there are multiple options, i.e. for add, separate versions is what it generates when there are no additional options, like for append), so I guess the hardest bits there have been tackled already...

I've now added what's generated by the current codegen so as to show current progress -- the intent being for it to replace the manually maintained file somehow (wouldn't mind a copy-paste, just wanted for contributors not to have to deal with the currying).

[ikatyang]

i.e. for add

Isn't it and ?!

EDIT: for R.and(), I'd suggest the signature like

function and<T, U>(a: T, b: U): T | U;

since the source code was just a && b.

I always look at the source code and think about what function signature should be, maybe I should record all the signature of R.XXX() first?

---

I've now added what's generated by the current codegen so as to show current progress -- the intent being for it to replace the manually maintained file somehow (wouldn't mind a copy-paste, just wanted for contributors not to have to deal with the currying).

I'd suggest making some scripts for copy-paste automatically, since copy-paste manually may make some mistakes.

---

I've done my codegen for merged version and fix the problem of ordering, but I think there may be some bugs since I haven't tested it in every case.

various

type map = map_00;
type map_00 = {
  <T>(_fn: PH, mappable: Mappable<T>): map_mappable_01<T>;
  <T>(_fn: PH, array: T[]): map_array_01<T>;
  <T, U>(fn: (v: T) => U, array: T[]): map_array_11<T, U>;
  <T, U>(fn: (v: T) => U, mappable: Mappable<T>): map_mappable_11<T, U>;
  <K extends "array", X extends "01">(): <T>(_fn: PH, array: T[]) => map_array_01<T>;
  <K extends "mappable">(): map_mappable_00;
  <X extends "1">(): <T, U>(fn: (v: T) => U) => map_10<T, U>;
  <K extends "array">(): map_array_00;
  <K extends "array", X extends "11">(): <T, U>(fn: (v: T) => U, array: T[]) => map_array_11<T, U>;
  <K extends "mappable", X extends "11">(): <T, U>(fn: (v: T) => U, mappable: Mappable<T>) => map_mappable_11<T, U>;
  <K extends "mappable", X extends "01">(): <T>(_fn: PH, mappable: Mappable<T>) => map_mappable_01<T>;
  <T, U>(fn: (v: T) => U): map_10<T, U>;
};
type map_10 = {
  (array: T[]): map_array_11<T, U>;
  <K extends "array">(): (array: T[]) => map_array_11<T, U>;
  <K extends "mappable">(): (mappable: Mappable<T>) => map_mappable_11<T, U>;
  (mappable: Mappable<T>): map_mappable_11<T, U>;
};
type map_array_00 = {
  <T>(_fn: PH, array: T[]): map_array_01<T>;
  <T, U>(fn: (v: T) => U, array: T[]): map_array_11<T, U>;
  <X extends "11">(): <T, U>(fn: (v: T) => U, array: T[]) => map_array_11<T, U>;
  <X extends "01">(): <T>(_fn: PH, array: T[]) => map_array_01<T>;
  <X extends "1">(): <T, U>(fn: (v: T) => U) => map_array_10<T, U>;
  <T, U>(fn: (v: T) => U): map_array_10<T, U>;
};
type map_array_01<T> = {
  <U>(fn: (v: T) => U): map_array_11<T, U>;
};
type map_array_10<T, U> = {
  (array: T[]): map_array_11<T, U>;
};
type map_array_11<T, U> = U[];
type map_mappable_00 = {
  <T>(_fn: PH, mappable: Mappable<T>): map_mappable_01<T>;
  <T, U>(fn: (v: T) => U, mappable: Mappable<T>): map_mappable_11<T, U>;
  <X extends "11">(): <T, U>(fn: (v: T) => U, mappable: Mappable<T>) => map_mappable_11<T, U>;
  <X extends "01">(): <T>(_fn: PH, mappable: Mappable<T>) => map_mappable_01<T>;
  <X extends "1">(): <T, U>(fn: (v: T) => U) => map_mappable_10<T, U>;
  <T, U>(fn: (v: T) => U): map_mappable_10<T, U>;
};
type map_mappable_01<T> = {
  <U>(fn: (v: T) => U): map_mappable_11<T, U>;
};
type map_mappable_10<T, U> = {
  (mappable: Mappable<T>): map_mappable_11<T, U>;
};
type map_mappable_11<T, U> = Mappable<U>;

normal

type adjust = adjust_000;
type adjust_000 = {
  <T, U>(fn: (v: T) => U, _index: PH, array: T[]): adjust_101<T, U>;
  <T>(_fn: PH, index: number, array: T[]): adjust_011<T>;
  <T>(_fn: PH, _index: PH, array: T[]): adjust_001<T>;
  <T, U>(fn: (v: T) => U, index: number, array: T[]): adjust_111<T, U>;
  (_fn: PH, index: number): adjust_010;
  <T, U>(fn: (v: T) => U, index: number): adjust_110<T, U>;
  <X extends "1">(): <T, U>(fn: (v: T) => U) => adjust_100<T, U>;
  <X extends "101">(): <T, U>(fn: (v: T) => U, _index: PH, array: T[]) => adjust_101<T, U>;
  <X extends "011">(): <T>(_fn: PH, index: number, array: T[]) => adjust_011<T>;
  <X extends "001">(): <T>(_fn: PH, _index: PH, array: T[]) => adjust_001<T>;
  <X extends "11">(): <T, U>(fn: (v: T) => U, index: number) => adjust_110<T, U>;
  <X extends "01">(): (_fn: PH, index: number) => adjust_010;
  <X extends "111">(): <T, U>(fn: (v: T) => U, index: number, array: T[]) => adjust_111<T, U>;
  <T, U>(fn: (v: T) => U): adjust_100<T, U>;
};
type adjust_001<T> = {
  (_fn: PH, index: number): adjust_011<T>;
  <U>(fn: (v: T) => U, index: number): adjust_111<T, U>;
  <X extends "11">(): <U>(fn: (v: T) => U, index: number) => adjust_111<T, U>;
  <X extends "01">(): (_fn: PH, index: number) => adjust_011<T>;
  <X extends "1">(): <U>(fn: (v: T) => U) => adjust_101<T, U>;
  <U>(fn: (v: T) => U): adjust_101<T, U>;
};
type adjust_010 = {
  <T>(_fn: PH, array: T[]): adjust_011<T>;
  <T, U>(fn: (v: T) => U, array: T[]): adjust_111<T, U>;
  <X extends "11">(): <T, U>(fn: (v: T) => U, array: T[]) => adjust_111<T, U>;
  <X extends "01">(): <T>(_fn: PH, array: T[]) => adjust_011<T>;
  <X extends "1">(): <T, U>(fn: (v: T) => U) => adjust_110<T, U>;
  <T, U>(fn: (v: T) => U): adjust_110<T, U>;
};
type adjust_011<T> = {
  <U>(fn: (v: T) => U): adjust_111<T, U>;
};
type adjust_100<T, U> = {
  (_index: PH, array: T[]): adjust_101<T, U>;
  (index: number, array: T[]): adjust_111<T, U>;
  <X extends "11">(): (index: number, array: T[]) => adjust_111<T, U>;
  <X extends "01">(): (_index: PH, array: T[]) => adjust_101<T, U>;
  <X extends "1">(): (index: number) => adjust_110<T, U>;
  (index: number): adjust_110<T, U>;
};
type adjust_101<T, U> = {
  (index: number): adjust_111<T, U>;
};
type adjust_110<T, U> = {
  (array: T[]): adjust_111<T, U>;
};
type adjust_111<T, U> = (T | U)[];

interfaces

interface CurriedFunction1<T1, R> {
  (v1: T1): R;
}
interface CurriedFunction2<T1, T2, R> {
  (_1: PH, v2: T2): CurriedFunction1<T1, R>;
  (v1: T1, v2: T2): R;
  (v1: T1): CurriedFunction1<T2, R>;
}
interface CurriedFunction3<T1, T2, T3, R> {
  (v1: T1, _2: PH, v3: T3): CurriedFunction1<T2, R>;
  (_1: PH, v2: T2, v3: T3): CurriedFunction1<T1, R>;
  (_1: PH, _2: PH, v3: T3): CurriedFunction2<T1, T2, R>;
  (v1: T1, v2: T2, v3: T3): R;
  (_1: PH, v2: T2): CurriedFunction2<T1, T3, R>;
  (v1: T1, v2: T2): CurriedFunction1<T3, R>;
  (v1: T1): CurriedFunction2<T2, T3, R>;
}

---

How can I do for this repo now? It is difficult for me to write the scripts (FP) here, since I am new to ramda and FP ( I just read the docs and haven't used it... ). Should I generate the dts using my version and make some PR or .. ?

[KiaraGrouwstra]

Isn't it and ?!

Both add and and have multiple, yeah. Just like map you used in your example just now. :)

I'd suggest making some scripts for copy-paste automatically

Yeah, fair enough.

How can I do for this repo now?

If you've already generated the CurriedFunction interfaces, feel free to update them here.

For the full typings, before I could merge a PR I'm thinking we'd probably need to finish the generated typings over here first so that we could test for the differences between them. I don't have much time for open-source recently though, so I realize that isn't helping much...

[ikatyang]

Both add and and have multiple, yeah. Just like map you used in your example just now. :)

add: {
  base: [
    ['T extends {and?: Function}'], // <--- I thought this is not for add...
    {
      fn1: 'T',
      val2: 'boolean+any'
    },
    'boolean'
  ],
  no_generics: [
    [],
    {
      v1: 'any',
      v2: 'any',
    },
    'boolean',
  ]
},

---

If you've already generated the CurriedFunction interfaces, feel free to update them here.
For the full typings, before I could merge a PR I'm thinking we'd probably need to finish the generated typings over here first so that we could test for the differences between them. I don't have much time for open-source recently though, so I realize that isn't helping much...

I thought that just updating the CurriedFunction interfaces does not make sense..

I'll try the full typings myself in my repo first, and we can mix them together or do something else while you have time to do such work :)

[KiaraGrouwstra]

I thought this is not for add...

Ouch, crap, thanks for noticing! Fixed now.

I thought that just updating the CurriedFunction interfaces does not make sense..

I know it'd only add partial support, but I'd think it'd still help a bit already, no? Anyway, no strong preference here -- as you prefer.

I'll try the full typings myself in my repo first, and we can mix them together or do something else while you have time to do such work :)

Fair enough, sorry for the trouble!

P.S.: Saw you're from Taiwan; pretty cool place. :D

[ikatyang]

I know it'd only add partial support, but I'd think it'd still help a bit already, no? Anyway, no strong preference here -- as you prefer.

Would you mind the CurriedFunction 1~9 to be 1000+ rows...

---

P.S.: Saw you're from Taiwan; pretty cool place. :D

😊

[KiaraGrouwstra]

Would you mind the CurriedFunction 1~9 to be 1000+ rows...

On that one, well...

I used to have similar codegen for the path function, trying to give it proper inference, which also ended up super long for 7~9. When I tried it, I could no longer compile my application anymore -- the path definition made it too slow. So then I just got rid of the longer segments.

I think a similar strategy could work well here. Fortunately, I think Ramda probably doesn't even really have many functions that have many parameters... so I imagine we could probably get away with ignoring the longer ones.

[ikatyang]

Curried1: 1 rows
Curried2: 3 rows
Curried3: 7 rows
Curried4: 15 rows
Curried5: 31 rows
Curried6: 63 rows
Curried7: 127 rows
Curried8: 255 rows
Curried9: 511 rows

I prefer 1 ~ 7 or 1 ~ 8, what do you think?

[KiaraGrouwstra]

My initial reflex would be toward 3-6 -- I feel a bit hesitant toward 7-9, since versions over 3 don't seem likely to be used much in practice (only in curry and invoker), while in my experience a big number of overloads could significantly affect compilation times.

That could become a concern for other typings with placeholder support as well. It'd be unfortunate if non-users would fall victim to that, so perhaps that could merit separate branches. Please feel free to experiment. Hopefully things will be fine.

[ikatyang]

I just rewrote my whole codegen library dts-element for v2, it is available to parse dts by using TS API now, so that my codegen is easily to understand now, and it will be restructured into this.

And I wrote a snapshot tester dts-jest base on jest and typings-checker, so that it will be easily to test with watching mode.

And I realize that there are some strange(?) typings in this repo that I can't just copy all of them, such as R.and, there is no andable parameters in the source file of Ramda.

Additionaly, Ramda v0.24.1 had just released.

Here's my progress now, any suggestion?