@gcaniti 는 소음에 대해 사과하고 추가 설명에 감사드립니다. 나는 논평하기 전에 더 많이 공부 했어야했다. 물론 펑터에는 인스턴스 구현이 필요하기 때문에 개념화의 오류입니다.

Afaics, 당신의 영리한 "해킹"은 일반적으로 팩토리를 참조 할 수있게 해주지 lift (예 : Option . 일반적인 팩토리의 모든 일반적인 사용에 대한 상용구가 필요하지 않습니까? 예를 들어 일반적인 sort 예제 @keean 과 제가 논의했습니다. 다른 코너 케이스도 발견 될 수 있습니까?

Kotlin이 아이디어를 복사 했나요? 아니면 그 반대인가요? (해당 링크에서 몇 가지 추가 비판이 있지만 Typescript 사례에 적용되는지 모르겠습니다)

나는 부정적이기를 원하지 않지만 자원을 이것에 투자하려는 경우 고려할 사항입니다.

그래 그 생각도 나에게 생겼다. 설명 해주셔서 감사합니다. 고려 사항 중 하나는 @masaeedu가 지적한 바와 같이 유형 시스템과 생성 할 수있는 모든 코너 케이스에 일반적으로 미치는 영향 일

_{참고 EMCAScript 컴파일 대상에 대한 투자 수준을 더 잘 확인하기 위해 Ceylon도 조사 ​​중입니다. (더 공부해야합니다).}

나는 또한이 한계에 물렸다. 다음 예제에서 I 를 자동으로 추론하고 싶습니다.

interface IdType<T> {
  id: T;
}

interface User {
  id: number;
  name: string;
}

function doStuff<T extends IdType<I>>() {
  const recs = new Map<I, T>();
  return {
    upsert(rec: T) {
      recs.set(rec.id, rec);
    },
    find(id: I) {
      return recs.get(id);
    },
  };
}

(function () {
  const stuff = doStuff<User>();
  stuff.upsert({id: 2, name: "greg"});
  console.log(stuff.find(2));
})();

내가 알 수있는 한, 이것은 더 높은 종류의 유형이 필요하거나 중복되는 것처럼 보이는 중복 일반 매개 변수 (예 : doStuff<User, number>() )를 지정해야합니다.

나는 최근에이 한계에 부딪혔다.

나는 약속 을위한

라이브러리의 핵심 기능은 안에 넣은 것과 동일한 유형의 promise를 반환한다는 것입니다. 따라서 Bluebird promise를 사용하고 함수 중 하나를 호출하면 제공하는 모든 추가 기능과 함께 Bluebird promise를 반환합니다.

나는 타입 시스템이 인코딩 싶었지만, 나는 빨리 유형 작업이 필요한 것을 깨달았다 P 종류의 * -> * 등이 P<T> extends Promise<T> .

다음은 이러한 기능 중 하나의 예입니다.

/**
* Returns a promise that waits for `this` to finish for an amount of time depending on the type of `deadline`.
* If `this` does not finish on time, `onTimeout` will be called. The returned promise will then behave like the promise returned by `onTimeout`.
* If `onTimeout` is not provided, the returned promise will reject with an Error.
*
* Note that any code already waiting on `this` to finish will still be waiting. The timeout only affects the returned promise.
* <strong i="14">@param</strong> deadline If a number, the time to wait in milliseconds. If a date, the date to wait for.
* <strong i="15">@param</strong> {() => Promise<*>} onTimeout Called to produce an alternative promise once `this` expires. Can be an async function.
*/
timeout(deadline : number | Date, onTimeout ?: () => PromiseLike<T>) : this;

위의 상황에서 나는 다소 해키 한 this 유형을 사용하여 더 높은 종류의 필요를 피할 수있었습니다.

그러나 다음과 같은 경우는 해결할 수 없습니다.

/**
* Returns a promise that will await `this` and all the promises in `others` to resolve and yield their results in an array.
* If a promise rejects, the returned promise will rejection with the reason of the first rejection.
* <strong i="21">@param</strong> {Promise<*>} others The other promises that must be resolved with this one.
* <strong i="22">@returns</strong> {Promise<*[]>} The return type is meant to be `Self<T[]>`, where `Self` is the promise type.
*/
and(...others : PromiseLike<T>[]) : ExtendedPromise<T[]>;

this<T[]> 것을 할 수있는 해킹이 없기 때문입니다.

문서에서 내 작은 사과를 기록하십시오.

위의 참조에서 알 수 있듯이이 기능이 유용 할 것이라고 생각하는 다른 시나리오가 있습니다 (제안을 올바르게 해석했다고 가정).

제네릭 유형은 일반적으로 사용자가 생성하므로 해당 패키지에서 유형이 지정되지 않은 제네릭 클래스 또는 함수를 유형으로 사용해야합니다.

내 시나리오에 제안을 적용하면 다음과 같이 보일 것이라고 생각합니다.

import { Component, FunctionalComponent } from 'preact';

interface IAsyncRouteProps {
    component?: Component<~,~> | FunctionalComponent<~>;
    getComponent?: (
        this: AsyncRoute,
        url: string,
        callback: (component: Component<~,~> | FunctionalComponent<~>) => void,
        props: any
    ) => Promise<any> | void;
    loading?: () => JSX.Element;
}

export default class AsyncRoute extends Component<IAsyncRouteProps, {}> {
    public render(): JSX.Element | null;
}

내 구현에서 제네릭 유형을 안정적으로 참조 할 방법이 없다는 점을 감안할 때 뭔가 놓친 것이 확실합니다.

@ Silic0nS0ldier 사실 그 사건은 지금 당장 해결할 수 있습니다. 다음과 같은 구조 생성자 유형을 사용합니다.

type ComponentConstructor = {
    new<A, B>() : Component<A, B>;
}

그런 다음 component ?: ComponentConstructor 라고 말합니다.

더 일반적으로, 실제로 일반 함수 유형을 가질 수 있습니다.

let f : <T>(x : T) => T

이를 rank-n 매개 변수 다형성이라고하며 실제로 언어에서 매우 드문 기능입니다. 따라서 TypeScript에 더 높은 종류의 유형이없는 이유는 훨씬 더 혼란 스럽습니다. 이는 훨씬 더 일반적인 기능입니다.

여기에서 설명하는 제한은 특정 TComponent<T, S> 를 참조해야하는 경우 나타납니다. 그러나 귀하의 경우 이것은 불필요하게 보입니다.

typeof Component 를 사용하여 생성자의 유형 인 Component 있지만 이로 인해 하위 유형에 다양한 문제가 발생합니다.

@GregRos 제안 된 솔루션이 유망 해 보였지만 (정의 파일 내의 유형을 허용 함) 호환 가능한 유형이 거부되었습니다. https://gist.github.com/Silic0nS0ldier/3c379367b5e6b1abd76e4a41d1be8217

@ Silic0nS0ldier 요점에 대한 내 의견을 참조하십시오.

@chrisdavies 작동합니까?

interface IdType<T> {
    id: T;
}

interface User {
    id: number;
    name: string;
}

function doStuff<T extends IdType<any>>() {
    type I = T['id']; // <==== Infer I
    const recs = new Map<I, T>();
    return {
        upsert(rec: T) {
            recs.set(rec.id, rec);
        },
        find(id: I) {
            return recs.get(id);
        },
    };
}

(function() {
    const stuff = doStuff<User>();
    stuff.upsert({ id: 2, name: "greg" });
    console.log(stuff.find(2));
})();

@ jack-williams 네. 그것은 내 시나리오에서 작동합니다. 나는 문서에서 그 예제를 찾지 못했습니다 (나는 누락 된 것으로 알려져 있지만!). 감사합니다!

나는이 기능에 대해 많이 생각하고 있고, 어떤 종류의 사양에 기대어 문제에 대해 약간의 생각이 있지만 여전히 많은 문제를 볼 수 있습니다. 내 제안은 지금까지 제안 된 것과 약간 다릅니다.

우선, 유형 생성자에 대해 T<*, *> 구문을 사용하는 것은 유형 생성자의 복잡성에 맞게 확장되지 않기 때문에 나쁜 생각이라고 생각합니다. 또한 참조 될 때마다 유형 생성자의 종류를 지정하는 것이 중요한지 확실하지 않습니다. 유형 매개 변수가있는 함수에 대해서도 함수에 대해이 작업을 수행하지 않기 때문입니다.

이를 구현하는 가장 좋은 방법은 일반 이름을 사용하여 다른 유형과 같이 고급 유형을 처리하고 제약 조건을 부과하는 데 사용할 수있는 유형 생성자 자체에 대해 좋은 하위 유형 관계를 정의하는 것입니다.

나는 우리가 다른 유형과 구별하기 위해 어떤 종류의 접두사 또는 접미사를 사용해야한다고 생각합니다. 주로 사용자가 일반 코드 만 작성하려고 할 때 유형 생성자와 관련된 이해할 수없는 오류 메시지로부터 사용자를 보호하기 위해서입니다. 저는 ~Type, ^Type, &Type 같은 모습을 좋아합니다.

예를 들어 함수 서명은 다음과 같습니다.

interface List<T> {
    push(x : T);
}

function mapList<~L extends ~List, A, B>(list : L<A>, f : (x : A) => B) : L<B>;

(고의적으로 구성된 유형에 ~ 접두사를 사용하지 않습니다)

여기서 extends 를 사용하여 기본적으로 두 가지를 말했습니다.

**1. 필요한 경우 : ~L 는 ~List 와 동일한 종류를 갖는 유형 생성자입니다. 즉, * -> * 종류 (또는 => 이후 * => * ) => 는 TypeScript 화살표입니다).

1. ~L 은 ~List 의 하위 유형입니다. **

유형 생성자의 종류를 나타 내기 위해 extends 를 사용하면 ((* => *) => (* => *)) => * 와 같은 것을 포함하여 임의의 복잡한 유형 생성자로 확장됩니다.

유형의 식별자에서 그런 종류를 실제로 볼 수는 없지만 필요하다고 생각하지 않습니다. 유형 생성자 간의 하위 유형 관계가 종류를 보존해야하는지 확실하지 않으므로 (1)이 필요하지 않을 수 있습니다.

불완전한 유형 생성 없음

불완전한 유형 생성을 지원해서는 안된다고 생각합니다. 즉, 다음과 같습니다.

(*, *) => * => *

나는 그것이 가치보다 더 많은 문제를 일으킬 것이라고 생각합니다. 즉, 모든 유형 생성자는 구체적인 유형을 생성해야하며 해당 구체적인 유형은 TC가 정의 된 컨텍스트에서 지정되어야합니다.

유형 생성자를 정의하는 구조적 방법

또한 매우 높은 순서의 제네릭 함수 유형을 포함하여 다른 유형을 구조적으로 지정할 수있는 것과 마찬가지로 유형 생성자를 지정하는 구조적 방법이 있어야한다고 생각합니다. 나는 다음과 같은 구문을 생각하고 있습니다.

~<A, B> { 
    a : A,
    b : B
}

유형 매개 변수가있는 함수 유형의 기존 구문과 유사합니다.

<A, B>() => { a : A, b : B};

이 두 가지를 결합하여 얻을 수도 있습니다.

~<A><B, C> => [A, B, C]

제네릭 함수 유형을 구성하는 유형 생성자입니다.

이점은 다른 구조 유형을 지정하거나 유형 제약 조건을 지정할 때 이러한 구조 유형을 사용할 수 있다는 것입니다. 때때로 이것은 다른 곳에서 참조 할 수없는 참조 지역 기호를 사용할 수 있음을 의미합니다.

다음은 그 예입니다.

type List<A, B> = ...;

type AdvancedType<~L extends ~<A>List<A, B>, B> = ...;

위의 예에서 구조적 유형 생성자 ~<A>List<A, B> 는 유형 매개 변수 B 합니다. 적어도 부분적으로 구성된 유형 List<A, *> 를 인코딩하지 않고는이 관계를 다른 방법으로 지정할 수 없습니다. 다른 예도 있습니다.

하위 유형 관계

하위 유형 관계는 의미가있는 것 같지만 특성화하는 데 많은 어려움이 있습니다.

내 첫 번째 아이디어는 다음과 같습니다. ~A 가 ~B 의 하위 유형이되는 경우 :

1. (a) 그것들은 동일한 종류를 가져야합니다 (제약이 아니라 arity 측면에서).
2. 모든 법적 파라미터 (나) T₁, T₂, ... 의 ~A , A<T₁, T₂, ...> 의 하위 유형이어야합니다 B<T₁, T₂, ...> .

그러나 여기에는 몇 가지 제한 사항이 있습니다.

1. MySpecialPromise 클래스 는 PromiseLike {}를 구현합니다.
   

2. MyArrayPromise 클래스PromiseLike 구현

   이 경우에도 하위 유형 관계가 보존되지 않습니다.

(b)의보다 일반화 된 버전은 다음과 같습니다.

모든 합법적 인 파라미터 (나) T₁, T₂, ... 의 ~A , 파라미터 화 존재 S₁, S₂, ... 의를 ~B 되도록 A<T₁, T₂, ...> 의 하위 유형 B<S₁, S₂, ...>

즉, 위의 속성을 가진 매핑 F (T₁, T₂, ...) = S₁, S₂, ...가 있습니다. 이 맵핑은 파라미터 구성하기 위해 사용되어야합니다 B<...> A는 파라미터에서 A<...> . 유형 생성자가 다른 종류를 가지고 있어도이를 수행 할 수 있습니다.

이 관계의 문제는 올바른 매핑을 찾을 수있는 방법을 잘 모르겠다는 것입니다. 명목상 타이핑을 사용하는 언어에서는 다음과 같은 모든 문장이 있습니다.

A<...> extends B<...>

~A 의 유형 매개 변수와 ~B 의 유형 매개 변수 간의 맵핑을 정의하므로 맵핑이 복구 될 수 있습니다. 그러나 TypeScript의 구조적 유형 체계에서는이 유형의 명시 적 진술에 의존 할 수 없습니다.

한 가지 방법은 implements 절이나 Scala와 유사한 일종의 추상 유형 멤버와 같은 올바른 유형 정보를 가진 유형에 대해서만 유형 생성자를 지원하는 것입니다. 그래도 이것이 앞으로 나아갈 길인지 확실하지 않습니다.

@GregRos- 흥미로운 메모! 몇 가지 질문입니다.

구체적인 유형이란 무엇을 의미합니까? * 종류를 가진 것을 의미합니까, 아니면 바인딩 된 유형 매개 변수가없는 유형을 의미합니까?

불완전한 유형 생성 없음
불완전한 유형 생성을 지원해서는 안된다고 생각합니다. 즉, 다음과 같습니다.
(*, *) => * => *

불완전한 유형을 구성한다는 것은 무엇을 의미합니까? L<A> 와 같은 모든 애플리케이션이 * ? 예를 들어 쌍 종류 생성자는 예를 들어 (* => *) => * => * 괜찮습니까?

유형 생성자를 정의하는 구조적 방법

~<A, B> { 
    a : A,
    b : B
}

inferface TyCon<A, B> { 
    a : A,
    b : B
}

첫 번째 예가 익명 인 것 외에 다른 예입니까?

하위 유형 관계

~A 및 ~B 는 유형을 참조하지 않으므로 하위 유형 관계를 갖는 것이 합리적입니까? 한 생성자가 다른 생성자의 '하위 유형'인지 실제로 언제 확인해야합니까? 생성자가 적용될 때까지 기다렸다가 결과 유형을 확인할 수 있습니까?

@ jack-williams 피드백 주셔서 감사합니다!

불완전한 유형을 구성한다는 것은 무엇을 의미합니까? L<A> 와 같은 모든 응용 프로그램에 종류 *가 있어야한다는 뜻입니까? 예를 들어 쌍 종류 생성자는 예를 들어 (* => *) => * => * 괜찮습니까?

네, 맞습니다. L<A> 와 같은 모든 애플리케이션에는 * 종류가 있어야합니다. 내가 어떻게 팔렸는지 잘 모르겠습니다.

첫 번째 예가 익명 인 것 외에 다른 예입니까?

첫 번째는 유형 표현식이고 두 번째는 선언입니다. 이러한 유형이 대부분의 측면에서 동일하다는 것과 같은 방식으로 대부분의 측면에서 동일합니다.

{
     a : number;
     b : string;
}

interface Blah {
    a : number;
    b : string;
}

구문에는 몇 가지 동기가 있습니다.

1. TypeScript의 다른 모든 것과 마찬가지로 형식 생성자를 구조적으로 익명으로 지정할 수 있습니다.
2. 함수의 형식 서명과 같이 선언문을 사용할 수없는 특정 컨텍스트에서 형식 식 (위에 언급 된 익명 개체 형식)을 사용할 수 있습니다. 이를 통해 로컬 식별자를 캡처하고 달리 표현할 수없는 것을 표현할 수 있습니다.

~A 및 ~B 는 유형을 참조하지 않으므로 하위 유형 관계를 갖는 것이 합리적입니까? 한 생성자가 다른 생성자의 '하위 유형'인지 실제로 언제 확인해야합니까? 생성자가 적용될 때까지 기다렸다가 결과 유형을 확인할 수 있습니까?

유형 생성자는 유형으로 간주되거나 간주되지 않을 수 있습니다. 나는 그것들을 값이없고 값의 유형을 요구하는 어떤 맥락에서도 나타날 수없는 불완전한 유형으로 간주 할 것을 제안합니다. 이것은 이 문서에서 Scala가 취한 것과 동일한 철학입니다.

하위 유형 관계 란 본질적으로 유형 생성자를 제한하는 데 사용할 수있는 일종의 "적합성"관계를 의미합니다. 예를 들어, Promise<T> , Bluebird<T> 등과 같은 다양한 유형의 모든 종류의 promise에서 작동하는 함수를 작성하려면 TC 매개 변수를 다음과 같이 제한 할 수있는 기능이 필요합니다. 인터페이스 PromiseLike<T> .

이러한 유형의 관계에 대한 자연스러운 단어는 하위 유형 관계입니다.

예를 살펴 보겠습니다. 유형 생성자 간의 하위 유형 관계를 해결했다고 가정하면 다음과 같은 함수를 작성할 수 있습니다.

function mapPromise<~P extends ~PromiseLike, A, B>(promise : P<A>, func : (x : A) => B) : P<B>;

그리고 제약 조건 ~P extends ~PromiseLike 은 이것이 promise에 대해 작동하는 함수이며 promise에만 작동 함을 보장합니다. 제약 조건은 또한 함수 본문 내에서 promise 를 구현하는 것으로 알려진 PromiseLike<A> 등을 보장합니다. 결국, 함수의 본문에 타이프에 의해 인식되는 회원은 정확하게 제약을 통해 존재 입증 할 수있는 것들이다.

동일한 방식으로 Promise<T> extends PromiseLike<T> , 구조적으로 호환되고 서로 대체 될 수 있기 때문에 ~Promise extends ~PromiseLike 구조적으로 호환 가능한 유형을 구성하므로 서로 대체 될 수 있기 때문입니다.

하위 유형 문제로 문제를 강조하려면 다시 한 번 고려하십시오.

interface MyPromise<T> extends Promise<T[]> {}

~Promise 추상화하는 것과 같은 방식으로 ~MyPromise 를 추상화 할 수 있습니까? 그들 사이의 관계를 어떻게 포착합니까?

앞서 이야기 매핑은의 파라미터를 지정해, 그 매핑입니다 ~MyPromise 의 파라미터 생성합니다, ~Promise 으로 구성 유형 너무을 ~MyPromise 의 서브 타입이다 하나는 ~Promise 의해 생성되었습니다.

이 경우 매핑은 다음과 같습니다.

T => T[]

뿡뿡

이 경우 ~MySpecialPromise 는 종류가 다르기 때문에 ~PromiseLike 의 하위 유형이 아닙니다.

Haskell에서 이러한 종류의 문제는 유형의 부분적 적용을 허용하고 유형을 정의하여 최종 유형 매개 변수가 구현중인 인터페이스의 유형 매개 변수와 일치하도록함으로써 해결됩니다.

귀하의 예에서 MySpecialPromise 는 MySpecialPromise<TSpecial, TPromiseVal> 로 정의되고 ~MySpecialPromise<SpecialType> 는 ~Promise 동일한 종류를 갖습니다.

뿡뿡

하위 유형 관계 란 본질적으로 유형 생성자를 제한하는 데 사용할 수있는 일종의 "적합성"관계를 의미합니다. 예를 들어 Promise와 같은 다양한 유형의 모든 종류의 약속에 대해 작동하는 함수를 작성하려면, 블루 버드등, PromiseLike 인터페이스로 TC 매개 변수를 제한하는 기능이 필요합니다.어떤 식 으로든.
function mapPromise<~P extends ~PromiseLike, A, B>(promise : P<A>, func : (x : A) => B) : P<B> ;

나는 그 함수를 유형 검사 할 때 선택한 T 대해 BlueBird<T> 및 PromiseLike<T> 를 통합하려고 시도 할 것이라고 생각합니다. 이들은 구체적인 유형일 뿐이며 하위 유형에 속합니다. 생성자 ~BlueBird 및 ~PromiseLike 대해 특별한 관계가 필요한 이유를 알 수 없습니다.

이런 식으로 사용될 것 같아요?

let x: <P extends ~PromiseLike>(input : P<A>, func : (x : A) => B) : P<B>;
let y: <P extends ~BlueBird>(input : P<A>, func : (x : A) => B) : P<B>;
x = y;

여기에서 y의 제약이 x의 제약을 의미하는지 확인하고 싶을 수 있지만 TypeScript에는 BlueBird<T> 가 사용할 수있는 PromiseLike<T> 를 확장하는지 확인하는 기계가 아직 없습니까?

@ jack-williams 다음과 같은 제약 조건을 지정하는 방법은 다음과 같습니다.

~ P는 모든 A 에 대해 P<A> 가 PromiseLike<A> 의 하위 유형이되는 유형 생성자입니다.

어떤 종류의 구문을 사용 하시겠습니까? 어떤 개념을 사용 하시겠습니까? 다음과 같이 작성할 수 있습니다.

function mapPromise<~P, A, B where P<A> extends PromiseLike<A>>

그러나이 구문에는 한계가 있습니다. 예를 들어이 클래스를 제한하기 위해 선언 된 지점에서 P<A> 유형을 구성 할 수 없기 때문에이 클래스를 전혀 표현할 수 없습니다.

class PromiseCreator<~P extends ~PromiseLike> {
    create<A>() : P<A>;
}

하지만 다음과 같이 실존 적 유형 을 사용할 수 있다고 생각합니다.

//Here A is not a captured type parameter
//It's an existential type we introduce to constrain ~P
class PromiseCreator<~P with some A where P<A> extends PromiseLike<A>> {
    create<A>() : P<A>;
}

그런 다음 선택적으로 존재 유형을 사용하여 함수 또는 유형의 서명 내에서 생성 된 유형을 통해 모든 유형 생성자를 제한하도록 요구할 수 있습니다.

실존 적 유형을 사용하면 매핑이있는 하위 유형 관계와 동일한 표현력을 갖게됩니다.

그러나 이것은 여러 가지 문제가 있습니다.

1. ((* => *) => *) => * 와 같은 종류로 유형 생성자를 지정하려면 많은 존재 유형을 도입해야하며, 그중 일부는 더 높은 순서 여야합니다. 그들 모두는 함수 또는 클래스의 시그니처에 sppear해야합니다.
2. 매핑을 찾는 것보다 문제의 실존 적 유형을 찾는 것이 더 쉬울 것이라고 확신하지 않습니다.
3. 하위 유형 관계보다 덜 우아하다고 생각합니다.
4. 처리해야 할 다른 유형의 유형을 잠재적으로 도입합니다.

뿡뿡

어떤 종류의 구문을 사용 하시겠습니까? 어떤 개념을 사용 하시겠습니까?

_ 개인적으로 _ 특별한 구문을 사용하지 않고 다음을 사용합니다.

function mapPromise<P extends PromiseLike, A, B>(p: P<A>, f: (x: A) => B): P<B>

class PromiseCreator<P extends PromiseLike> {
    create<A>() : P<A>;
}

그러나 이것은 number 와 같은 것을 null-ary 생성자로 보는 내 의견 일뿐입니다. 따라서 구별 할 필요가 없습니다.

생성자 함수의 하위 유형에 대한 나의 견해는 가능한 한 간단하게 유지하는 것입니다. 그것들은 동일한 배열을 가져야하며 매개 변수는 스칼라 논문과 매우 유사한 반 변성 및 공분산을 고려하여 서로의 하위 종류 여야합니다.

부분 응용 프로그램은 서로 다른 arity를 ​​가진 경우를 처리 할 수 ​​있습니다 (유형 생성자에 대해 자동 커링을 신경 쓰지 않으므로 MySpecialPromise<SpecialType> 작성할 수 있습니다).

interface MyPromise<T> extends Promise<T[]> {} 예제에서 저는 솔직히 말해야하며,이 경우를 처리하는 것이 복잡 할 가치가 있다고 확신하지 않습니다. 이것이 없으면 충분히 유용한 기능이라고 생각합니다.

이 경우를 처리하는 것은 ~MyPromise extends ~(Promise . []) 여기서 [] 는 목록 생성자이고 . 는 생성자 구성입니다. 이제는 생성자의 구조를 검사하는 것만으로는 충분하지 않지만 구성에 대해서도 추론해야하므로 상황이 훨씬 더 어려워지는 것 같습니다!

@ jack-williams 이것은 기본 유형 매개 변수와 함께 작동하지 않습니다. P extends Foo 하면 Foo 에 기본 유형 매개 변수 (예 : type Foo<T = {}> = ... )가있는 경우 P 의 종류는 무엇입니까?

나는 고차 유형을 승인한다고 말하고 싶습니다 (실제 TypeScript 프로젝트에서 유용 할 수있는 상황이있었습니다).

그러나 나는 그들이 카레를 지원해야한다고 생각 하지 않는다 . 나는 Haskell을 좋아하지만 TypeScript와는 맞지 않습니다.

고차 유형은 커링이나 부분 적용 없이도 유용하지만 부분 적용이 필요한 경우 명시적인 구문을 보는 것이 좋습니다. 이 같은:

Foo<number, _>  // equivalent to `type Foo1<A> = Foo<number, A>`

@ cameron-martin

편집 : 죄송합니다. 내 의견이 명확하지 않은 것 같습니다. P 에는 고유 한 종류가 있습니다. 즉, 사용에 따라 종류가 부과됩니다. 제약 조건은 항상 가장 높은 종류로 간주되므로 Foo 는 ~Foo 간주됩니다. P 를 더 낮은 종류로 강제하는 경우에만 Foo 에 기본 매개 변수가 있는지 확인합니다. 이것에 대한 나의 관심은 친절한 추론이지만,이 경우 ~ 도움이되지 않으며 완전한 주석이 필요하다고 생각합니다.

P 자체 종류가 있지 않나요? 질문은 우리가 Foo 를 ~Foo 로 취급하거나 Foo<{}> 취급하지 않겠습니까? 나는 그것이 P의 종류에 의해 구동 될 것이라고 주장합니다. 따라서 P 는 기본 매개 변수를 강제하는 유형이며 P 가 생성자 * => * 이면 Foo 를 동일하게 처리합니다.

@Pauan 귀하의 제안에 동의하십시오.

@ jack-williams 앞서 언급했듯이 하위 입력의 개념을 고려했습니다.

내 첫 번째 아이디어는 다음과 같습니다. ~A 가 ~B 의 하위 유형이되는 경우 :

1. (a) 그것들은 동일한 종류를 가져야합니다 (제약이 아니라 arity 측면에서).
2. 모든 법적 파라미터 (나) T₁, T₂, ... 의 ~A , A<T₁, T₂, ...> 의 하위 유형이어야합니다 B<T₁, T₂, ...> .

문제는 가능한 한 단순하게 유지하면 역설적이며 언어에 맞지 않는 하위 유형 관계로 끝날 것이라는 것입니다.

경우 MyPromise<T> extends Promise<T[]> 수단은 MyPromise<T> 있다가 가능한 것으로 어디든지 Promise<T[]> 가능한 없지만, 이것은 더 이상 사건이 될 것입니다.

as 를 사용하여 a : MyPromise<T> 를 Promise<T[]> 로 변환하면 업 캐스팅이 될 수 있지만 역설적으로 a 더 할당 할 수 있습니다.

기존 하위 유형 관계를 따르는 기존 일반 제약 조건을 사용하여 유사한 효과를 얻고 이상한 동작을 일으킬 수도 있습니다.

function id1<A, ~P extends ~PromiseLike>(p : P<A>) : P<A>;

function id2<A, P extends Promise<A[]>>(p : P) : P {
    //ERROR - P does not extend PromiseLike<A>
    return id1(p);
}

타이핑도 부작용으로 적어도 부분적으로 명목이 될 것입니다. 이러한 유형은 갑자기 달라지며 현재는 동일합니다.

type GenericNumber<T> = number;

type RegularNumber = number;

유형 매개 변수, 순전히 구조적 유형, 멤버 이해가있는 유형 등을 사용하는 복잡한 공용체 / 교차 유형에 어떤 영향을 미칠지 확신 할 수 없습니다.

내 개인적인 느낌은 다음과 같습니다 . 유형 생성자에 대한 하위 유형 관계는 기존 유형을 반대하는 것이 아니라 존중해야합니다 . 안타깝게도 이것은 일이 더 복잡해야합니다.

타입 생성자에 대한 특별한 표기법의 어떤 종류를 사용하는 가장 큰 이유는 개발자의 99 %는 타입 생성자가 무엇인지 모르는 그들에 대한 오류 메시지와 함께 폭격 싶지 않을 것이다 것입니다.

이것은 모든 개발자가 범주 이론의 고급 과정을 수강해야하는 법률에 따라 Haskell과는 매우 다릅니다.

두 번째 이유는 (앞서 언급 한 기본 매개 변수의 경우와 같이) 어떤 경우에는 구문이 모호하거나 특정 유형 생성자를 전혀 추상화 할 수 없기 때문입니다.

편집 : 죄송합니다 @GregRos 후자의 의견을 보지 못했습니다!

유형 생성자에 대한 하위 유형 관계는 기존 생성자를 존중해야하며 반대하지 않아야합니다.

이것이 달성 될 수 있다면 동의합니다. 나는 모든 세부 사항과 이것이 얼마나 쉬운 지에 대해 내 머리를 가지고 있지 않았습니다.

두 번째 이유는 (앞서 언급 한 기본 매개 변수의 경우와 같이) 어떤 경우에는 구문이 모호하거나 특정 유형 생성자를 전혀 추상화 할 수 없기 때문입니다.

나는 당신이 더 낮아질 필요가있을 때까지 항상 가장 높은 종류의 제약을 가정한다면 그것이 모호 할 것이라는 데 동의하지 않습니다. 이것은 주장이 아니며 그렇지 않으면 충분히 공정한 다른 예가 있다면.

문제는 가능한 한 단순하게 유지하면 역설적이며 언어에 맞지 않는 하위 유형 관계로 끝날 것이라는 것입니다.

그것은 사실 일 수 있습니다. 저는 대안이 실제로 구현 될 수 있는지에 대해 우려하고 있습니다. 더 복잡한 솔루션이 작동한다면 그만한 가치가 있습니다!

매핑 기능의 존재를 보여주는 더 일반적인 하위 유형 개념을 갖는 것은 일반적으로 구현하기 어려운 것 같습니다. 다음 예가 규칙을 올바르게 해석하고 있습니까?

(b) ~ A의 모든 유효한 매개 변수화 T₁, T₂, ...에 대해 ~ B의 매개 변수화 S₁, S₂, ...가 있습니다.

F (A, B) = (number, B)의 매핑이 주어지면 X는 다음 경우 Y의 하위 유형이됩니다.

type X = ~<A,B> = {x : B};
type Y = ~<A,B> = A extends number ? {x: B} : never;

그러나 X<string,number> 은 Y<string,number> 의 하위 유형이 아닙니다.

매핑의 _ 존재 _가 충분한 지 확실하지 않은 것 같습니다. ~ A와 ~ B를 함수로 사용하고 ~ B가 ~ A에 가깝거나 ~ A가 ~ B의 하위 유형임을 보여주고 싶다면 ~ A가 a가되는 일부 함수 ~ C가 있음을 보여줍니다. (~ B. ~ C)의 하위 유형은 충분하지 않습니다 (C는 매퍼입니다). _all_ 매핑의 경우가되어야합니다.

function id1<A, ~P extends ~PromiseLike>(p : P<A>) : P<A>;

function id2<A, P extends Promise<A[]>>(p : P) : P {
    //ERROR - P does not extend PromiseLike<A>
    return id1(p);
}

이 예제를 따르지 않습니다. 여기서 오류가 발생하지 않아야합니까? 이것에 대한 나의 독서는 id1 는 모든 _inputs_에 대해 PromiseLike 를주는 함수 P 의해 구성된 입력을 가져야한다는 것입니다. id2 는 A []에 Promise를 적용하는 하위 유형이어야하는 값에 대해 이야기하고 있습니다. id2 유형에서 id1 필요한 정보를 복구 할 수 있는지 잘 모르겠습니다. 그래도 당신의 요점을 오해하고있을 것 같아요.

이러한 유형은 갑자기 달라지며 현재는 동일합니다.

다시 말하지만, 나는 당신의 요점을 놓치고 있을지도 모르지만 그들이 어떻게 같은지 모릅니다. 유형에서 RegularNumber 를 GenericNumber 로 바꿀 수 없습니다. 후자에 인수를 지정해야합니다.

매핑의 존재가 충분한 지 확실하지 않은 것 같습니다. ~ A와 ~ B를 함수로 사용하고 ~ B가 ~ A에 가깝거나 ~ A가 ~ B의 하위 유형임을 보여주고 싶다면 ~ A가 a가되는 일부 함수 ~ C가 있음을 보여줍니다. (~ B. ~ C)의 하위 유형은 충분하지 않습니다 (C는 매퍼입니다). 나는 모든 매핑의 경우가되어야합니다.

네, 당신 말이 맞고 당신이 제공 한 반례도 그렇습니다. 다른 반례를 찾았습니다. 전혀 작동하지 않습니다.

이 스레드와 많은 답변을 다시 읽었습니다. 나는 당신이 많은 일에서 옳다고 생각하고 나는 문제를 잘못된 방식으로보고 있습니다. 내가 의미하는 바를 이해하겠습니다.

나는 당신이 더 낮아질 필요가있을 때까지 항상 가장 높은 종류의 제약을 가정한다면 그것이 모호 할 것이라는 데 동의하지 않습니다. 이것은 주장이 아니며 그렇지 않으면 충분히 공정한 다른 예가 있다면.

모호하거나 참조가 불가능 해집니다. 위의 예 에서처럼 Foo 의 형식 생성자는 형식 자체에 의해 숨겨져 있으므로 참조 할 수 없게됩니다. ~Foo 또는 그 문제에 대해 Foo<*> 또는 ~<A>Foo<A> 또는 다른 항목과 충돌하지 않는 다른 항목을 작성하면 이런 종류의 문제가 발생하지 않습니다.

예, 별명을 정의하여 해결할 수 있습니다.

type Foo2<T> = Foo<T>

제가 말했듯이, 이것이 가장 중요한 관심사라고 생각하지 않습니다.

이 예제를 따르지 않습니다. 여기서 오류가 발생하지 않아야합니까? 내가 읽은 내용은 id1이 모든 입력에 대해 PromiseLike를 제공하는 함수 P에 의해 구성된 입력을 가져야한다는 것입니다. id2는 A []에 Promise를 적용하는 하위 유형이어야하는 값에 대해 이야기하고 있습니다. id2 유형에서 id1에 필요한 정보를 복구 할 수 있는지 잘 모르겠습니다. 그래도 당신의 요점을 오해하고있을 것 같아요.

맞습니다. 예. 그러나 P extends Promise<A[]> 이면 id1 와 같이 Promise<A[]> 를 허용하는 모든 장소에 할당 할 수 있어야합니다. 이것이 바로 지금의 방식이며 서브 타이핑의 의미입니다.

더 이상 피할 수 없다고 생각합니다.

다시 말하지만, 나는 당신의 요점을 놓치고 있을지도 모르지만 그들이 어떻게 같은지 모릅니다. 형식에서 RegularNumber를 GenericNumber로 바꿀 수는 없습니다. 후자에 인수를 지정해야합니다.

내가 의미하는 바는 GenericNumber<T> 유형, 모든 T 및 유형 RegularNumber 는 동일하고 상호 교환이 가능하다는 것입니다. 하나는 check를 입력하고 다른 하나는 입력하지 않는 컨텍스트가 없습니다. 지금 당장은 적어도.

우리가 이야기 한 것은 그것들을 다르게 만들 것입니다. GenericNumber<T> 는 최우수 사용자의 것이기 때문에 RegularNumber 이 (가) 될 수없는 곳에서도 검색이 가능합니다. 따라서 더 이상 상호 교환 할 수 없습니다.

나는 이것에 대해 생각해 보았고 그것은 피할 수 없을 수도 있고 반드시 나쁜 것은 아닐 수도 있다고 생각합니다. 새롭고 다른 행동입니다.

그것에 대해 생각하는 한 가지 방법은 유형 매개 변수가 유형의 "구조"의 일부가되는 것입니다.

최우수 사용자가 좀 더 다른 행동으로 이어질 것이라고 생각합니다.

새로운 방향

우선, 올바른 하위 유형 관계가 매핑이없는 관계라는 점에서 옳다고 생각합니다.

내 첫 번째 아이디어는 다음과 같습니다. ~A 가 ~B 의 하위 유형이되는 경우 :

1. (a) 그것들은 동일한 종류를 가져야합니다 (제약이 아니라 arity 측면에서).
2. 모든 법적 파라미터 (나) T₁, T₂, ... 의 ~A , A<T₁, T₂, ...> 의 하위 유형이어야합니다 B<T₁, T₂, ...> .

매핑 문제는 ... 솔직히, 꽤 멍청합니다. 더 이상 MyPromise<T> extends Promise<T[]> 와 ~Promise 를 통합 할 방법이 없다고 생각합니다. 누군가가 다르게 생각하는지 알고 싶습니다.

이 규칙조차도 작동하지 않는 곳에서 누락 된 예가 있는지도 알고 싶습니다.

형식 생성자 제약 조건이 매우 잘 작동하는 것처럼 보이는 하위 형식 관계를 사용하여 표현되어야한다는 데 동의하면 다른 것으로 이동할 수 있습니다.

구문 정보

우리는이 주제에 대해 정말로 동의하지 않는 것 같습니다. ~Promise 와 유사한 접두사 구문을 강력히 선호합니다. 개념적으로 ~ 는 "TC에 대한 참조"연산자 또는 그 밖의 것으로 볼 수 있습니다.

대안보다 나은 이유를 몇 가지 제시했다고 생각합니다.

1. 완전히 모호하지 않습니다.
   
   
   
   1. 이 구문과 관련된 오류도 명확합니다. 누군가 유형을 매개 변수화하는 것을 잊은 경우 유형 생성자가 무엇인지 모를 때 유형 생성자에 대한 오류가 발생하지 않습니다.
   
   
   2. 부작용으로 기존 오류 텍스트 및 논리를 변경할 필요가 없습니다. 누군가 Promise 쓰면 오류 메시지는 지금과 똑같습니다. 최우수 사용자에 대해 이야기하기 위해 변경할 필요가 없습니다.
   
   
2. 구조적 구문으로 잘 확장됩니다.
3. 파싱하기 쉽다고 생각합니다. 유형이 예상되는 곳에 나타나는 모든 ~\w 는 TC에 대한 참조를 나타내는 것으로 간주됩니다.
4. 입력하기 쉽습니다.

다른 사람들이 의견을 줄 수 있기를 바랍니다.

공용체, 교차점 및 기본 유형 매개 변수 정보

* & (* => *) , * | (* => *) 등의 오버로드 / 혼합 된 종류가 합법적인가요? 흥미로운 용도가 있습니까?

나는 그들이 나쁜 생각이고 추론하기 어렵다고 생각합니다. 또한 유형을 구성 할 수 있도록 * | (* => *) 명확히하기 위해 어떤 종류의 주석이 필요한지 잘 모르겠습니다.

이러한 종류가 현재 존재한다고 말할 수있는 한 가지 방법은 기본 형식 매개 변수를 사용하는 형식입니다.

type Example<A = number> = {}

이 유형은 유형을 구성하기 위해 유형 매개 변수를 허용 할 수 있기 때문에 * & (* => *) 유형을 갖는다 고 할 수 있지만 반드시 그럴 필요는 없습니다.

기본 형식 매개 변수는 형식을 설명하는 방법이 아니라 속기 형식이어야한다고 생각합니다. 따라서 유형의 종류를 결정할 때 기본 유형 매개 변수를 무시해야한다고 생각합니다.

그러나 ~Promise | ~Array 와 같은 유형에 대해 이야기하는 것이 좋습니다. 그것들은 같은 종류이므로 호환되지 않습니다. 나는 이것이 지원 되어야 한다고 생각

처리해야 할 것

다음과 같은 관련 상황을 처리해야합니다.

type Example = (<~P extends ~Promise>() => P<number>) | (<~M extends ~Map>() => Map<string, number>);

그러나 이것은 실제로 (* => *) | (*, *) => * 종류를 포함하지는 않지만 다른

다른 최우수 사용자를 구성 하시나요?

앞서 언급했듯이 * => (* => *) 와 같이 다른 최우수 사용자를 구성하는 최우수 사용자를 보유하는 것은 좋지 않다고 생각합니다. 커링 등을 지원하는 언어에서는 표준이지만 TypeScript에서는 그렇지 않습니다.

~ 구문과 하위 유형 관계를 사용하여 이러한 유형을 정의하는 방법이 전혀 없으므로이를 금지하기위한 특별한 규칙이 필요하지 않습니다. 작동하려면 특별한 규칙이 필요합니다.

다음과 같이 구조적으로 정의 할 수 있다고 생각합니다.

~<A>~<B>{a : A, b : B}

그것이 제가 생각하는 유일한 방법입니다.

상위 기능과의 상호 작용?

유형 매개 변수를 사용하는 함수 유형과 자연 스럽지만 복잡한 상호 작용이 있습니다.

type Example<T> = <~P extends ~Promise>(p : P<T>) : P<T>;

이 상호 작용을 어떻게 든 중지해야합니까? 이러한 유형이 매우 복잡 해지는 것을 볼 수 있습니다.

일반적으로 TC 매개 변수가 표시되지 않아야하는 장소가 있습니까?

내 구조적 구문이 좋은 생각입니까?

당장 구현되어야한다고 생각하지는 않지만 여전히 구조적 구문이 좋은 생각이라고 생각합니다. 다음을 수행 할 수 있습니다.

1. 제약 조건에서 다른 유형 매개 변수와 같은 로컬 식별자를 사용합니다.
2. ~<A>Map<string, A> , ~<A, B>Map<B, A> 등 매우 명시적이고 유연한 방식으로 유형 생성자를 부분적으로 적용합니다.
3. 유형의 다른 모든 측면에는 구조적 구문이 있으므로 TC도 이러한 구문을 가져야합니다.

즉, 최우수 사용자는 이것이 없이도 완전히 일할 수 있으며 첫 번째 PR에는 아마도 참여자가 없을 것입니다.

조건부 유형과의 상호 작용

기능이 조건부 유형과 어떻게 작동합니까? 이것을 할 수 있어야합니까?

type Example<~P extends ~PromiseLike> = ~P extends ~Promise ? 0 : 1

나는 내 자신을 완전히 확신하지 못합니다. 아직 조건부 유형을 완전히 소화하지 못했습니다.

과부하 해결

나는 이것이하기 어려울 것이라고 생각한다. 이것은 서로 다른 형태의 과부하 해결이 결국 서로 다른 유형을 구성하기 때문에 실제로 매우 중요합니다.

즉, 지금 당장은 좋은 예를 찾을 수 없습니다.

잘 정의 된 중간 언어가 TypeScript를 시작점으로 설명하는 데 사용 되었다면 이것의 대부분은 논쟁 점이되었을 것입니다. 예 : System F <: 또는 Simplified Dependent ML 과 같은 사운드 종속 유형 시스템 중 하나.

이게 전에 해결된다면 솔직히 놀라 겠어
https://github.com/Microsoft/TypeScript/issues/14833

나는 # 17961이 아마도 이것을 간접적으로 해결할 수 있다고 생각합니다. 자세한 내용은 이 요점 을 참조하십시오.

Bifunctor 및 Profunctor 유형은 제약 수준에서 약간 복잡합니다. infer T 대신 작업 할 명백한 범용 유형이 있다면 훨씬 간단합니다 this 를 "return"유형 (순수한 유형 수준)으로 사용할 수 있다면 좋을 것입니다. 그러면 대부분의 인터페이스를 정의하기가 더 쉬워 졌을 것입니다.

(저는 무거운 TS 사용자가 아니기 때문에 실수를했을 수도 있습니다. @ tycho01 제가 유형 엉망이 된 곳이 있는지 확인하기 위해

@isiahmeadows @ tycho01 와우 ...

네가 옳아. 올바르게 이해하면 거의 동일한 결과를 얻습니다.

몇 가지 차이점이 있습니다. 그러나 기능적으로는 거의 동일하며 이러한 차이를 해결할 수 있다고 생각합니다.

올바른 유형 함수를 추론 할 수 없음

function example<~P extends ~PromiseLike>(p : P<number>) : P<string>;

여기서 ~Bluebird 에서 p ~Promise 및 ~Bluebird 를 추론 할 수 있습니다. 그러나 다음과 같이하면 :

function example<F extends <T>(t: T) => PromiseLike<T>>(p : F(number)) : F(string)

이것이 효과가 있을지 의심 스럽습니다.

example(null as Promise<number>)

F 가 다음과 같음을 유추 할 방법이 없습니다.

<T>(t : T) => Promise<T>

이 기능은 어떤 식 으로든 특별하다고 간주되지 않기 때문입니다. TC와 달리 일부 유형은 본질적으로 "암시 적"유형 수준 함수 인 TC를 갖습니다.

기존 TC를 쉽게 참조 할 수 없음

내 제안 에서처럼 ~Promise 할 수 없습니다. 구조적 형식을 사용하여 유형을 직접 인코딩해야합니다.

type PromiseTC = <T>() => Promise<T>

사실, 그것은 관심사입니다. 이는 알려진 인수 유형에서 제네릭 함수 자체를 추론 할 수있는 기능이 필요한 유형 추론 문제에 가깝습니다 (일반적으로 발생하는 것과 반대). 대부분의 경우에 작동하기에 충분히 일반적인 방식으로 해결할 수 있지만 사소하지 않은 새로운 특수 사례가 필요합니다.

NoInfer<T> 의 전략적인 사용을 통해 부분적으로 해결할 수 있을지 모르지만, 어떻게해야하는지, 일반적인 경우에도 얼마나 처리 할 수 ​​있는지 100 % 확신 할 수 없습니다.

뿡뿡

나는 어떤 구문을 강력히 선호하지 않으며 그것은 내 선호에 더 가깝습니다. ~ 에는 많은 장점이 있습니다. 추론이 항상 가능하지는 않기 때문에 명시적인 종류 주석에 대한 구문이 필요한지 여부를 고려해야 할 주요 사항이 있다고 생각합니다.

매핑 문제는 ... 솔직히, 꽤 멍청합니다. MyPromise를 통합 할 방법이 없다고 생각합니다.약속 연장

나는 매핑 것은 여전히 유용한 개념이 될 수 있다고 생각하지만, 경우에 우리가 지금까지 통합을 시도해야한다고 생각하지 않는 이상 ~MyPromise 와 ~Promise , 필요에 통합 될 수 있다는 것 ~MyPromise 및 ~<T>Promise<T[]> 이며 ~(Promise . []) 쓸 수도 있습니다. 누락 된 점은 매핑이 하위 유형 관계의 일부 여야한다는 것입니다. Promise 만큼 생성자의 일부입니다. 이 예에서 매핑은 목록 생성자 일뿐입니다.

interface A<T> {
    x: T;
} 

interface B<T> {
    x: T[];
}

~<T>B<T> ~<T>A<T[]> 연장합니까? 예. ~<T>B<T> ~<T>A<T> 연장합니까? 아니요.하지만 궁극적으로 두 가지 관련없는 질문입니다.

형식 생성자 제약 조건이 매우 잘 작동하는 것처럼 보이는 하위 형식 관계를 사용하여 표현되어야한다는 데 동의하면 다른 것으로 이동할 수 있습니다.

예, 나는 그것이 사물을 설명하는 좋은 방법 인 것 같습니다.

올바른 유형 함수를 추론 할 수 없음

function example<~P extends ~PromiseLike>(p : P<number>) : P<string>;
여기에서 p에서 ~Promise 및 ~Bluebird 를 추론 할 수 있습니다.

이것은 유형 검사가 어떻게 작동하는지 완전히 확신하지 못하기 때문에 주장이 아니며 더 열린 질문입니다. 위의 인터페이스 A 예로 들어 A<number> 및 {x: number} 은 구별 할 수 없으므로 생성자를 추론 할 수 있을지 확신이 없습니다. 생성자의 응용 프로그램에서 반환 된 형식에서 P<number> 에서 P 를 회수 할 수 있습니까? 나는 이것을 지원하기 위해 상황이 바뀔 수 있다고 확신합니다. 나는 그것이 지금 무엇을하는지 궁금합니다.

# 17961의 교차 응답이지만, 불행히도 @isiahmeadows 의 접근 방식이 작동하도록하는 방법을 잘 모르겠습니다. 유형 호출에 대한 역 추론이 사소하지 않을까 두렵습니다.

그래서 입력에 따라 모양 Promise<number> 또는 Bluebird<number> 우리는 우리가 예와 재신들을 수있는 등 이러한 유형의 적용되지 않은 버전 추론 할 수 싶어 string . 그래도 힘든 것 같습니다.

입력 유형이 구조적으로 동등한 것 대신에 이와 같더라도 (우리는 구조적으로 유형화 된 언어입니다. 맞습니까?), 예를 들어 Bluebird 대신 두 개의 매개 변수 유형이있는 경우이 추론도 모호해집니다 <string> 유형 매개 변수 애플리케이션이 더 이상 의미가 없을 수 있습니다.
거기에 좋은 해결책이 확실하지 않습니다. (면책 조항 : 여기서 논의에서 약간 뒤쳐졌습니다.)

@ tycho01 사람들이 T 명시 적으로 인스턴스화하면이 모든 문제가 사라질까 요?

어쨌든 모든 경우에 대해 추론이 해결 될 수 있을지 의심 스럽기 때문에 그것은 합리적이라고 생각합니다.

@ jack-williams : 지금까지 # 17961은 아니지만 디스패치를 ​​위해 사용하는 것이 도움이 될 것이라고 생각합니다.

let arr = [1, 2, 3];
let inc = (n: number) => n + 1;
let c = arr.map(inc); // number[]
let map = <Functor extends { map: Function }, Fn extends Function>(x: Functor, f: Fn) => x['map'](f); // any on 2.7 :(
let e = map(arr, inc);

@ tycho01 예, T 가 메서드 호출에서 인스턴스화되지 않았기 때문에 내 제안이 끔찍하다는 것을 깨달았습니다.

다음 작업을 원하십니까?

interface TyCon<A> {
    C: <A>(x: A) => TyCon<A>
}

interface Functor<A> extends TyCon<A> {
    C: <A>(x: A) => Functor<A>;
    fmap<B>(this: this["C"](A), f: (x: A) => B): this["C"](B);
}

interface Option<A> extends Functor<A> {
    C: <A>(x: A) => Option<A>;
}

@ jack-williams 나는 그것이 fp-ts 의 ADT 구현과 동작면에서 어떻게 비교되는지에 대한 질문이되어야한다고 생각하지만 이것은 작동 할 수있는 것처럼 보인다. 아마도 TyCon 없을 수도 있습니다.

@ jack-williams @isiahmeadows :

이미 $Call 사용 가능하므로 try flow 에서 아이디어를

interface Functor<A> {
    C: <A>(x: A) => Functor<A>;
    fmap<B>(f: (x: A) => B): $Call<$ElementType<this, "C">, B>;
}
// this: $Call<$ElementType<this, "C">, A>, 
// ^ flow doesn't seem to do `this` params

interface Option<A> extends Functor<A> {
    C: <A>(x: A) => Option<A>;
}

let o: Option<string>;
let f: (s: string) => number;
let b = o.fmap(f);

@ tycho01 흐름에서 this 에서 $ElementType 로 속성을 얻을 수 없다고 생각합니다.

@ tycho01 실제로 타이프 스크립트에서도 작동하도록 할 수 없습니다.
플레이 그라운드 : https://goo.gl/tMBKyJ

@goodmind : 흠, Functor 에서 Maybe fmap 복사 한 후 Functor<number> Maybe<number> 대신
유형 호출을 사용하면 유형에 대한 런타임 구현이 필요하지 않고 유형 만있는 것이 향상 될 것이라고 생각합니다.
이제 functor는 이미 자체 fmap 구현이 필요합니다. 그래도 파생 된 메서드 는 짜증나게됩니다.
원점으로 돌아가다. : /

https://github.com/SimonMeskens/TypeProps/issues/1 에서 몇 가지 관련 아이디어

최대한 빨리 알파 버전을 출시 할 계획이지만, 그 문제에 대한 예제를 작성하여 저와 함께 따라갈 수 있습니다.

이 특정 문제는 전체적으로 다루기에는 조금 길지만 제가 찾고있는 것은 간단하지만 매개 변수화 된 제네릭 유형이 없기 때문에 입력 할 수없는 코드의 실제 예제입니다. 나는 그들 대부분을 타이핑 할 수 있다고 생각한다 (추상 리프트 타입 생성자에 의존하지 않는다면). 코드를 사용하여 위의 repo에서 문제를 자유롭게 열어보고 가능한 경우 입력 해 드리겠습니다 (또는 여기에 게시 할 수도 있음).

참고로 # 23809에서이를 구현하기 시작했습니다. 여전히 매우 불완전하지만 관심이 있다면 확인하십시오.

저는 여러분들에게 간단한 예를 약속했습니다. 여기 있습니다. 이것은 내 라이브러리를 작성하면서 배운 몇 가지 트릭을 사용합니다.

type unknown = {} | null | undefined;

// Functor
interface StaticFunctor<G> {
    map<F extends Generic<G>, U>(
        transform: (a: Parameters<F>[0]) => U,
        mappable: F
    ): Generic<F, [U]>;
}

// Examples
const arrayFunctor: StaticFunctor<any[]> = {
    map: <A, B>(fn: (a: A) => B, fa: A[]): B[] => {
        return fa.map(fn);
    }
};
const objectFunctor: StaticFunctor<object> = {
    map: <A, B>(fn: (a: A) => B, fa: A): B => {
        return fn(fa);
    }
};
const nullableFunctor: StaticFunctor<object | null | undefined> = {
    map: <A, B>(
        fn: (a: A) => B,
        fa: A | null | undefined
    ): B | null | undefined => {
        return fa != undefined ? fn(fa) : fa;
    }
};

const doubler = (x: number) => x * 2;

const xs = arrayFunctor.map(doubler, [4, 2]); // xs: number[]
const x = objectFunctor.map(doubler, 42); // x: number
const xNull = nullableFunctor.map(doubler, null); // xNull: null
const xSome = nullableFunctor.map(doubler, 4 as number | undefined); // xSome: number | undefined

const functor: StaticFunctor<unknown | any[]> = {
    map(fn, fa) {
        return Array.isArray(fa)
            ? arrayFunctor.map(fn, fa)
            : fa != undefined
                ? objectFunctor.map(fn, fa)
                : nullableFunctor.map(fn, fa);
    }
};

const ys = functor.map(doubler, [4, 2]); // ys: number[]
const y = functor.map(doubler, 42); // y: number
const yNull = functor.map(doubler, null); // yNull: null
const ySome = functor.map(doubler, 42 as number | undefined); // ySome: number | undefined

// Plumbing
interface TypeProps<T = {}, Params extends ArrayLike<any> = never> {
    array: {
        infer: T extends Array<infer A> ? [A] : never;
        construct: Params[0][];
    };
    null: {
        infer: null extends T ? [never] : never;
        construct: null;
    };
    undefined: {
        infer: undefined extends T ? [never] : never;
        construct: undefined;
    };
    unfound: {
        infer: [NonNullable<T>];
        construct: Params[0];
    };
}

type Match<T> = T extends infer U
    ? ({} extends U ? any
        : TypeProps<U>[Exclude<keyof TypeProps, "unfound">]["infer"]) extends never
    ? "unfound"
    : {
        [Key in Exclude<keyof TypeProps, "unfound">]:
        TypeProps<T>[Key]["infer"] extends never
        ? never : Key
    }[Exclude<keyof TypeProps, "unfound">] : never;


type Parameters<T> = TypeProps<T>[Match<T>]["infer"];

type Generic<
    T,
    Params extends ArrayLike<any> = ArrayLike<any>,
    > = TypeProps<T, Params>[Match<T>]["construct"];

샘플을 업데이트하고 단순화했습니다. 여기에 플레이 그라운드 링크도 있습니다.
운동장

위의 NPM 라이브러리를 추가하여 더 쉽게 작업 할 수 있습니다. 적절한 테스트를 받기 전까지는 현재 알파 버전이지만 HKT를 작성하는 데 도움이 될 것입니다.

Github 링크

조건부 유형을 사용하여 포화 유형 내에서 가상 유형 변수를 대체하여 HKT를 시뮬레이션하는 간단한 접근 방식을 사용해 왔습니다.

declare const index: unique symbol;

// A type for representing type variables
type _<N extends number = 0> = { [index]: N };

// Type application (substitutes type variables with types)
type $<T, S, N extends number = 0> =
  T extends _<N> ? S :
  T extends undefined | null | boolean | string | number ? T :
  T extends Array<infer A> ? $Array<A, S, N> :
  T extends (x: infer I) => infer O ? (x: $<I, S, N>) => $<O, S, N> :
  T extends object ? { [K in keyof T]: $<T[K], S, N> } :
  T;

interface $Array<T, S, N extends number> extends Array<$<T, S, N>> {}

// Let's declare some familiar type classes...

interface Functor<F> {
  map: <A, B>(fa: $<F, A>, f: (a: A) => B) => $<F, B>;
}

interface Monad<M> {
  pure: <A>(a: A) => $<M, A>;
  bind: <A, B>(ma: $<M, A>, f: (a: A) => $<M, B>) => $<M, B>;
}

interface MonadLib<M> extends Monad<M>, Functor<M> {
  join: <A>(mma: $<M, $<M, A>>) => $<M, A>;
  // sequence, etc...
}

const Monad = <M>({ pure, bind }: Monad<M>): MonadLib<M> => ({
  pure,
  bind,
  map: (ma, f) => bind(ma, a => pure(f(a))),
  join: mma => bind(mma, ma => ma),
});

// ... and an instance

type Maybe<A> = { tag: 'none' } | { tag: 'some'; value: A };
const none: Maybe<never> = { tag: 'none' };
const some = <A>(value: A): Maybe<A> => ({ tag: 'some', value });

const { map, join } = Monad<Maybe<_>>({
  pure: some,
  bind: (ma, f) => ma.tag === 'some' ? f(ma.value) : ma,
});

// Not sure why the `<number>` annotation is required here...
const result = map(join<number>(some(some(42))), n => n + 1);
expect(result).toEqual(some(43));

여기 프로젝트 : https://github.com/pelotom/hkts

피드백 환영합니다!

@pelotom 나는 당신의 접근 방식의 구문의 가벼움을 좋아합니다. 이 스레드에서 아직 언급되지 않은 두 가지 다른 접근 방식이 현재 및 미래 솔루션이 생성되는 방식에 약간의 창의성을 불러 일으킬 수 있습니다. 둘 다이 문제에 대한 객체 지향 솔루션입니다.

1. Bertrand Meyer는 그의 1988 년 저서 "Object-oriented Software Construction"에서 제네릭 유형을 시뮬레이션하는 방법을 설명했습니다.

예제는 Eiffel에 있지만 TypeScript에 대한 대략적인 번역은 다음과 같습니다.

https://gist.github.com/mlhaufe/089004abd14ad8e7171e2a122198637f

중간 클래스 표현이 필요하기 때문에 상당히 무거워 질 수 있지만 클래스 팩토리 형식이나 TypeScript Mixin 접근 방식을 사용하면이 작업을 크게 줄일 수 있습니다.

# 17588에 일부 적용 가능성이있을 수 있습니다.

1. 두 번째 접근 방식은 객체 대수 (및 추상 팩토리)를 시뮬레이션 할 때 사용됩니다.

C<T> 는 App<t,T> 여기서 T 는 클래스이고 t 는 C 와 연결된 고유 태그입니다.

interface App<C,T> {}

견본:

interface IApp<C,T> {}

interface IList<C> {
    Nil<T>(): IApp<C,T>
    Cons<T>(head: T, tail: IList<C>): IApp<C,T>
}

// defining data
abstract class List<T> implements IApp<typeof List, T> {
    // type-safe down-cast
    static prj<U>(app: IApp<typeof List, U>): List<U> { return app as List<U> }
}
class Nil<T> extends List<T> { }
class Cons<T> extends List<T> {
    constructor(readonly head: T, readonly tail: List<T>) {
        super()
    }
}

// The abstract factory where the HKT is needed
class ListFactory<T> implements IList<typeof List> {
    Nil<T>(): IApp<typeof List, T> { return new Nil() }
    Cons<T>(head: T, tail: IApp<typeof List, T>): IApp<typeof List, T> {
        return new Cons(head, tail)
    }
}

3.5 "Emulating Type-Constructor Polymorphism"섹션의 다음 문서에서 자세한 내용과 타당성을 확인할 수 있습니다.

https://blog.acolyer.org/2015/08/13/streams-a-la-carte-extensible-pipelines-with-object-algebras/

@metaweta ,이 문제의 이름을 Higher kinded types in TypeScript 하여 Google 검색에서 더 나은 가시성을 얻을 수 있습니까?

아마도 우리의 현명하고 자비로운 저장소 관리자 (예 : @RyanCavanaugh , @DanielRosenwasser )는 그러한 변경이 개입 할 가치가 있다고 판단되면 제목을 편집 할 수 있습니까?

이것이 커뮤니티에서 백 로그로 옮겨 졌다는 것이 무엇을 의미하는지 궁금합니다. 이것은 핵심 팀이 지금 더 심각하게 고려하고있는 것입니까, 아니면 단순히 팀이 이것이 좋은 커뮤니티 후보가 아니라고 결정했음을 의미합니까?

발견 : "커뮤니티"이정표는 "백 로그"를 위해 더 이상 사용되지 않으므로이 문제는 아마도 현물로 마이그레이션되었을 것입니다.

TS 회원이 아니라, 다시 마일스톤이 된 링크를 클릭하기로 결정한 사람입니다.

+1

고급 유형에 대한 실제 사례처럼 보이는 제가 방금 구축하려고했던 것이 있습니다.

동기식 또는 비동기식으로 실행할 수있는 데이터베이스에 대한 추상화를 만들고 싶습니다. 콜백을 사용하고 해킹하기보다는 제네릭을 사용하고 싶었습니다. 내가 원하는 것은 다음과 같습니다.

type Identity<T> = T

interface DatabaseStorage<Wrap<T> extends Promise<T> | Identity<T>> {
    get(key: string): Wrap<any>
    set(key: string, value: any): Wrap<void>
}

이것은 정말 강력 할 것입니다!

@ccorcos 는 MTL 스타일이라고합니다. https://github.com/gcanti/fp-ts/blob/master/tutorials/mtl.ts 에서 fp-ts 를 사용한 순수 기능 예제를 살펴볼 수 있습니다.

@mlegenhausen 미안하지만 그 예를 따르는 데 어려움이 있습니다.

fp-ts 파헤칠 때마다 상황이 너무 복잡 해져서 부서지기 쉬워 질 까봐 걱정됩니다. @pelotom 의 예는 따라하기가 더 쉬워 보입니다 ...

이것이 TypeScript에 채택되지 않는 이유는 무엇입니까?

@ccorcos IMHO에서 fp-ts 의 예제를 추천해도 MTL / 태그없는 스타일은 전혀 권장하지 않습니다. 수동으로 관리해야하는 모든 효과적인 모나드에 추가 추상화 계층을 추가하면 typescript가 사용하려는 모나드를 감지 할 수 없기 때문에 상황이 복잡해집니다. fp-ts 커뮤니티에서 볼 수있는 것은 하나의 비동기 모나드 ( TaskEither 권장)를 사용하는 것입니다. 테스트 에서조차 MTL의 이점은 테스트하지 않는 코드에서 얻는 번거 로움의 가치가 없습니다. fp-ts 기반의 hyper-ts 는 최근 MTL 지원을 중단 한 라이브러리의 한 예입니다.

흥미 롭 네요 ... hyper-ts 정말 멋져 보입니다 ...

F-bounded polymorphism을 기반으로 한 경량의 고급 유형 인코딩을 생각해 냈습니다 : https://github.com/strax/tshkt

이 접근 방식의 이점은 형식 생성자를 형식에 연결하는 데 조회 테이블 (단일 조건부 형식 또는 문자열 키가있는 개체)이 필요 없다는 것입니다. 이 기술은 유형 수준 제네릭 함수의 응용 프로그램을 인코딩하는데도 ​​사용할 수 있습니다 (예 ReturnType<<T>(value: T) => Array<T>> ).

이는 여전히 개념 증명이므로이 접근 방식의 실행 가능성에 대한 피드백을 높이 평가합니다!

정말 멋져 보이는 @strax를 살펴 보겠습니다!

한편, 지금 우리가 할 수있는 일에 대한 어리석은 예가 있습니다.

type Test1 = λ<Not, [True]>;        // False
type Test2 = λ<And, [True, False]>; // False
type Test3 = λ<And, [True, True]>;  // True

// Boolean

interface True extends Func {
    expression: Var<this, 0>;
}

interface False extends Func {
    expression: Var<this, 1>;
}

interface Not extends Func {
    expression: λ<Var<this, 0>, [False, True]>
}

interface And extends Func {
    expression: λ<Var<this, 0>, [Var<this, 1>, Var<this, 0>]>
}

// Plumbing

type Func = {
    variables: Func[];
    expression: unknown;
}

type Var<F extends Func, X extends number> = F["variables"][X];

type λ<Exp extends Func, Vars extends unknown[]> = (Exp & {
    variables: Vars;
})["expression"];

더 이상 인터페이스가 필요하지 않음을 의미하기 때문에 De Bruijn 인덱스를 추가하고 싶지만 튜플 수학이 필요하다고 생각하고 피하려고합니다.

신청

고차, Lamda, 참조 유형

유형을 참조로 전달

간단히 말해서, 참조 유형 또는 더 높은 순서 유형 은 나중에 유형이 취한 매개 변수를 연기하거나 나중에 유형 매개 변수 (제네릭)를 추론 할 수 있습니다. 하지만 우리는 왜 신경을 써야합니까?

유형을 참조로 전달할 수 있다면 TypeScript가 유형을 평가하기로 결정할 때까지 지연시킬 수 있습니다. 실제 사례를 살펴 보겠습니다.

Pipe로 미리보기

pipe 대한 제네릭 유형을 개발하고 있다고 가정 해보십시오. 대부분의 작업은 파이프 할 함수가 실제로 파이프 가능한지 확인하는 것입니다. 그렇지 않으면 사용자에게 오류가 발생합니다. 이를 위해 매핑 된 유형을 사용하여 pipe(...) 와 같은 함수 유형을 파이프합니다.

type  PipeSync<Fns  extends  Function[], K  extends  keyof  Fns> = 
    K  extends  '0'
    // If it's the first function, we leave it unchanged
    ?  Fns[K]
    // For all the other functions, we link input<-output
    : (arg:  Return<Fns[Pos<Prev<IterationOf<K & string>>>]>) =>
        Return<Fns[Pos<IterationOf<K & string>>]>;

이제 매핑 된 유형이있는 함수에 대해 이것을 반복해야합니다.

type  Piper<Fns  extends  Function[]> = {
    [K  in  keyof  Fns]:  PipeSync<Fns, K>
}

( 전체 구현 참조 )

이제 우리는 함수를 함께 파이프 할 수 있고 TypeScript는 경고를 줄 수 있습니다.

declare  function  pipe<Fns  extends  F.Function[]>(...args:  F.Piper<Fns>):  F.Pipe<Fns>

const  piped  =  pipe(
    (name:  string, age:  number) => ({name, age}),
    (info: {name:  string, age:  number}) =>  `Welcome, ${info.name}`,
    (message:  object) =>  false, // /!\ ERROR
)

효과가있다! 적절한 오류가 있습니다.

'(message : object) => boolean'유형의 인수는 '(arg : string) => boolean'유형의 매개 변수에 할당 할 수 없습니다.

문제

하지만 문제가 있습니다. 이것은 간단한 작업에 매우 잘 작동하지만 전달하는 함수에 제네릭 (템플릿)을 사용하기 시작하면 완전히 실패한다는 것을 알 수 있습니다.

const  piped  =  pipe(
    (a:  string) =>  a,
    <B>(b:  B) =>  b, // any
    <C>(c:  C) =>  c, // any
)

type  piped  =  Piper<[
    (a:  string) =>  string,
    <B>(b:  B) =>  B,
    <C>(c:  C) =>  C,
]>
// [
//     (a:  string) =>  string,
//     (b:  string) =>  unknown,
//     (c:  unknown) => unknown
// ]

두 경우 모두 TypeScript는 함수 유형을 추적하지 못했습니다.
> 이것은 고차원 유형이 작용하는 곳입니다 <

통사론

type  PipeSync<Fns  extends  Function[], K  extends  keyof  Fns> = 
    K  extends  '0'
    // If it's the first function, we leave it unchanged
+   ?  *(Fns[K]) // this will preserve the generics
    // For all the other functions, we link input<-output
+   :  *( // <- Any type can be made a reference
+       <T>(arg:  T) => Return<*(Fns[Pos<IterationOf<K  &  string>>])>
+       // vvv It is now a reference, we can assign generics
+       )<Return<*(Fns[Pos<Prev<IterationOf<K  &  string>>>])>>
+       // ^^^ We also tell TS not to evaluate the previous return
+       // and this could be achieved by making it a reference too

간단히 말해, * 하여 제네릭을 수동 및 동적으로 추론했습니다. 실제로 * 를 사용하면 제네릭 평가가 지연되었습니다. 따라서 * 은 상황에 따라 다른 동작을합니다. * 가 다음 유형에있는 경우 :

• 제네릭을받을 수 있음 :
• 일반 자체 : 참조가 알려질 때까지 평가를 연기합니다. 이를 위해 참조 트리가 상위에서 아래로 작성됩니다. 즉, 굴절이 중첩 될 수 있습니다. 이것은 T 할당 된 Return<*(Fns[Pos<Prev<IterationOf<K & string>>>])> 정확히 발생합니다. 이러한 맥락에서 * 는 즉각적인 평가로부터 "보호"한다고 말할 수 있습니다.
• 위의 어느 것도 아님 : 아무것도하지 않고 동일한 유형으로 해석됩니다.

type  piped  =  Piper<[
    (a:  string) =>  string,
    <B>(b:  B) =>  B
    <C>(c:  C) =>  C
]>
// [
//     (a:  string) =>  string,
//     (b:  string) =>  string,
//     (c:  string) =>  string
// ]

따라서 TypeScript는 제네릭이 제공된 경우에만 평가를 시작 / 계속하고 필요할 때 평가를 차단해야합니다 (불완전한 제네릭). 현재 TS는 제네릭을 unknown 유형으로 전환하여 한 번에 평가합니다. 이 제안으로 무언가를 해결할 수없는 경우 :

type  piped  =  Piper<[
    <A>(a:  A) =>  A, // ?
    <B>(b:  B) =>  B, // ?
    <C>(c:  C) =>  C, // ?
]>
// [
//     <A>(a:  A) =>  A,
//     (b:  A) =>  A,
//     (c:  A) =>  A
// ]

세부

* 는 유형에 대한 참조를 검색하여 해당 제네릭에 대한 조작을 가능하게합니다. 따라서 유형 앞에 와일드 카드를 배치하면 이에 대한 참조가 검색됩니다.

*[type]

유형에 대한 참조를 검색하면 자동으로 제네릭 조작이 가능합니다.

*[type]<T0, T1, T2...>

제네릭은 가능한 경우 대상 유형에 의해서만 사용 / 설정됩니다. 이렇게하면 :

*string<object, null> // Will resolve to `string`

그러나 경고를 표시해야하는지 여부는 TypeScript 자체에서 확인할 수도 있습니다. 그러나 내부적으로 TS는이 작업을 수행하지 않아야합니다.

또한 * 를 사용하는 것이 좋은 생각이라고 생각했습니다. C / C ++ 언어에서와 같이 무언가에 대한 포인터를 상징 할 수 있고 TypeScript에서 차용하지 않기 때문입니다.

고등 주문 유형

이제 가장 기본적인 형태로 작동하는 방식을 살펴 보았으므로 핵심 개념 인 람다 유형 을 소개하고자 JavaScript의 콜백, 람다, 참조 와 유사한 익명 유형을 가질 수 있으면 좋을 것입니다.

위의 예는 함수의 제네릭을 인수하는 방법을 보여줍니다. 그러나 참조에 대해 이야기하고 있기 때문에 * 와 함께 모든 유형을 사용할 수 있습니다. 간단히 말해, 유형 참조는 전달할 수 있지만 아직 제네릭을받지 못한 유형입니다.

type  A<T  extends  string> = {0:  T}
type  B<T  extends  string> = [T]
type  C<T  extends  number> = 42

// Here's our lamda
type  Referer<*Ref<T  extends  string>, T  extends  string> =  Ref<T>
// Notice that `T` & `T` are not in conflict
// Because they're bound to their own scopes

type  testA  =  Referer<A, 'hi'> // {0: 'hi'}
type  testB  =  Referer<B, 'hi'> // ['hi']
type  testC  =  Referer<C, 'hi'> // ERROR

더 높은 종류의 유형

interface Monad<*T<X extends any>> {
  map<A, B>(f: (a: A) => B): T<A> => T<B>;
  lift<A>(a: A): T<A>;
  join<A>(tta: T<T<A>>): T<A>;
}

검색어

더 높은 # 순서 # 유형 # 참조 # 람다 #HKT

@ pirix-gh 메시지를 몇 개만 읽으면 요청한 내용이 이미 가능하거나 이미 요청되었음을 알 수 있습니다.

나는 그것들을 읽었고, 다른 모든 사람들처럼 (올인원 솔루션의 경우) 대부분 구문에 대한 내 아이디어를 요약 할 수 있다고 생각했습니다.

참조를 연결하는 방법에 대한 더 나은 설명을 위해 위의 제안을 편집하고 Pipe 와 같은 유형이 작동하는 방식을 수정했습니다 (논리와 관련하여 몇 가지 실수가있었습니다).

모든 업데이트?

아직 업데이트가 없습니까? 제 생각에이 문제는 TypeScript의 잠재력을 최대한 발휘하는 데 가장 큰 장애물로 평가됩니다. 내가이 한계에 다시 부딪쳤다는 것을 깨닫고 오랫동안 고군분투 한 후에 만 ​​포기하기 위해 내 라이브러리를 올바르게 입력하려고하는 경우가 너무 많습니다. 매우 단순한 시나리오에서도 나타나며 널리 퍼져 있습니다. 곧 해결되기를 바랍니다.

interface Monad<T<X>> {
    map1<A, B>(f: (a: A) => B): (something: A) => B;

    map<A, B>(f: (a: A) => B): (something: T<A>) => T<B>;

    lift<A>(a: A): T<A>;
    join<A>(tta: T<T<A>>): T<A>;
}

type sn = (tmp: string) => number

function MONAD(m: Monad<Set>,f:sn) {
    var w = m.map1(f);    // (method) Monad<Set>.map1<string, number>(f: (a: string) => number): (something: string) => number
    var w2 = m.map(f);    // (method) Monad<Set>.map<string, number>(f: (a: string) => number): (something: Set<string>) => Set<number>
    var q = m.lift(1);    // (method) Monad<Set>.lift<number>(a: number): Set<number>
    var a = new Set<Set<number>>();
    var w = m.join(q);    // (method) Monad<Set>.join<unknown>(tta: Set<Set<unknown>>): Set<unknown>.  You could see that typeParameter infer does not work for now.
    var w1 = m.join<number>(q);    // (method) Monad<Set>.join<number>(tta: Set<Set<number>>): Set<number>
}

빠른 정보 수정, typeParameter 추론, 오류 메시지 추가, 동일한 typeConstructor 강조 표시와 같은 많은 작업이 여전히 수행되어야합니다.
하지만 작동하기 시작했고 여기에 지금 당장 얻을 수있는 것이 있습니다.
예제 인터페이스는 @millsp https://github.com/microsoft/TypeScript/issues/1213#issuecomment -523245130입니다. 결론은 정말 도움이됩니다.

communicity가 대부분의 상황에서 현재 방식이 작동하는지 확인하기 위해 더 많은 사용자 사례를 제공 할 수 있기를 바랍니다.

HKT / 함수 프로그래밍 / 람다에 대한 정보를 제공하는 것도 좋을 것입니다 ( lambda 라고 말하면 수학을 의미합니다. 수학없이 일부 언어로 작성된 예제 만 찾을 수있었습니다)

다음은 저에게 많은 도움이되는 것입니다.

• http://adriaanm.github.io/files/higher.pdf
  
  
  
  • 이 백서의 BNF에 따라 파서를 변경합니다.
  
  

@ShuiRuTian m.join(q) Set<unknown> m.join(q) 반환하는 것과 관련하여 --noImplicitAny 이 (가) 경고를 발생 시킨다고 가정합니다.

나는 커뮤니티가 대부분의 상황에서 현재 방식이 작동하는지 확인하기 위해 더 많은 사용자 사례를 제공 할 수 있기를 바랍니다.

HKT / 함수 프로그래밍 / 람다에 대한 정보를 제공하는 것도 좋을 것입니다 ( lambda 라고 말하면 수학을 의미합니다. 수학없이 일부 언어로 작성된 예제 만 찾을 수있었습니다)

더 이상 진행하지 않고 최근에 일반적인 카레 filter 함수를 만들려고 시도했으며 다음과 같은 작업을 수행하기를 원했습니다.

const filterNumbers = filter(
    (item: number | string): item is number => typeof item === "number"
);

const array = ["foo", 1, 2, "bar"]; // (number | string)[]
const customObject = new CustomObject(); // CustomObject<number | string>

filterNumbers(array); // number[] inferred
filterNumbers(customObjectWithFilterFunction); // CustomObject<number> inferred

그리고 실제로 그렇게 할 수있는 방법이 없습니다. TypeScript에 "받은 것과 같은 유형을 반환하지만이 다른 매개 변수를 사용하여 반환"하는 방법이 필요하기 때문입니다. 이 같은:

const filter = <Item, FilteredItem>(predicate: (item: Item) => item is FilteredItem) =>
  <Filterable<~>>(source: Filterable<Item>): Filterable<FilteredItem> => source.filter(predicate);

@lukeshiru 예, 본질적으로 이것은 https://pursuit.purescript.org/packages/purescript-filterable/2.0.1/docs/Data.Filterable#v : filter
TypeScript에는 HKT에 대한 다른 유사한 사용 사례가 많이 있습니다.

@isiahmeadows 나는 그것을 시도했다. 당신이 옳습니다.
@lukeshiru 및 @raveclassic 감사합니다! 이 기능은 꽤 괜찮은 것 같습니다. https://gcanti.github.io/fp-ts/learning-resources/ 를 읽은 후 이것을 살펴볼 것입니다.

나는 막혔고 현재 모르겠습니다 ...
체인 사양 을 구현하려고합니다.

m['fantasy-land/chain'](f)

Chain 사양을 구현하는 값은 Apply 사양도 구현해야합니다.

a['fantasy-land/ap'](b)

FunctorSimplex 를 한 다음 FunctorComplex 로 확장 한 다음 Apply 로 확장했지만 이제 Apply 를 Chain 로 확장하려고합니다.

그래서 나는 그것이 필요합니다 (아래 이미지와 코드 링크).

(나는 유형을 ApType 에 전달하여 12 행에서 Apply 가 «하드 코딩 된»이 아니라 일반 ... IApply 에서 확장 된 유형도 취하도록해야합니다.

7ff8b9c의 11 ~ 22 행 코드 스 니펫에 대한 영구 링크

```타입 스크립트
내보내기 유형 ApType = ( ap : 적용 <(val : A) => B>, ) => IApply ;

/ * [...] * /

내보내기 인터페이스 IApply extends FunctorComplex {
/ ** Fantasy-land/ap :: Apply f => f a ~> f (a -> b) -> f b * /
ap : ApType ;
}
```

스택 오버플로 질문 : TypeScript 일반 유형 문제 참조 : 해결 방법 필요