Why does then extend chain?

[ccorcos]

Because then has two type definitions, there are a bunch of type errors that I've missed.

It would be nice if then was distinctly different from chain.

		/**
		 * returns a new parser which tries parser, and on success calls the given function
		 * with the result of the parse, which is expected to return another parser, which
		 * will be tried next
		 */
		chain<U>(next: (result: T) => Parser<U>): Parser<U>;
		/**
		 * returns a new parser which tries parser, and on success calls the given function
		 * with the result of the parse, which is expected to return another parser.
		 */
		then<U>(call: (result: T) => Parser<U>): Parser<U>;
		/**
		 * expects anotherParser to follow parser, and yields the result of anotherParser.
		 * NB: the result of parser here is ignored.
		 */
		// tslint:disable-next-line:unified-signatures
		then<U>(anotherParser: Parser<U>): Parser<U>;

[wavebeem]

Hi @ccorcos! I do not maintain the @types/parsimmon package and have never given any input on it. This would be a bug to report to the DefinitelyTyped project.

However, I will say this appears to be a bug in the type definitions, as the then<U>(call: (result: T) => Parser<U>): Parser<U> signature for then has not been supported since pre-1.x Parsimmon.

I am strongly considering adding TypeScript support directly to Parsimmon in the future, but there are various difficulties keeping me from adding it to Parsimmon 1.x and you will probably need to wait until 2.x for official support.

[ccorcos]

Sound good, thanks @wavebeem. I highly recommend TypeScript btw 👍

[wavebeem]

@ccorcos I love TypeScript too :) It's just difficult to get some of Parsimmon's idioms working well in TypeScript, and ES Classes have some strange features that don't mesh well with Parsimmon either. But I definitely wanna get in on it for this library eventually.

[wavebeem]

If you have any additional thoughts about TypeScript for Parsimmon, feel free to discuss here #230