Using prototype in records

**I propose we** Use prototype in records

```fsharp
type Production = string list

type ProductionsCrew =
{mainProductions:Set; augmentedProductions:Set}

type NullableCrew =
{prototype:ProductionsCrew;symbols:Set;nonterminals:Set;terminals:Set;nullables:Set}

type GrammarCrew =
{prototype:NullableCrew;firsts:Map>;lasts:Map>;follows:Map>;precedes:Map>}

```

A prototype chain is a type inheritance, Referencing fields in prototype records can omit prototype

```fsharp
let g: GrammarCrew =..
let prods = g.prototype.prototype.augmentedProductions
let prods = g.augmentedProductions
```

All function parameters of the base class can be applied to the data of the derived class.

```fsharp
let letftmost (nullable:NullableCrew ) = ()

let n: NullableCrew = ..
leftmost n //ok

let g: GrammarCrew =..
leftmost g //ok

```
**The existing way of approaching this problem in F# is** ...

```fsharp
type Production = string list

type ProductionsCrew(mainProductions:Set, augmentedProductions:Set) =
member _.mainProductions = mainProductions
member _.augmentedProductions = augmentedProductions

type NullableCrew(crew:ProductionsCrew,symbols:Set,nonterminals:Set,terminals:Set,nullables:Set) =
inherit ProductionsCrew(crew.mainProductions,crew.augmentedProductions)
member _.symbols = symbols
member _.nonterminals = nonterminals
member _.terminals = terminals
member _.nullables = nullables

type GrammarCrew(crew:NullableCrew,firsts:Map>,lasts:Map>,follows:Map>,precedes:Map>) =
inherit NullableCrew(ProductionsCrew(crew.mainProductions,crew.augmentedProductions),crew.symbols,crew.nonterminals,crew.terminals,crew.nullables)
member _.firsts = firsts
member _.lasts = lasts
member _.follows = follows
member _.precedes = precedes
```
## Pros and Cons

**The advantages of making this adjustment to F# are** ...

* Simpler code

* Reduced one base class construction when initializing derived classes

**The disadvantages of making this adjustment to F# are** ...

* The prototype class must be reference transparent, with the same input parameters, and the class must be equivalent.

* I don't know how to solve the problem of duplicate names on the prototype chain yet. I suggest not allowing duplicate names for now.

## Extra information

**Estimated cost (XS, S, M, L, XL, XXL):**

**Related suggestions:** (put links to related suggestions here)

## Affidavit (please submit!)

Please tick these items by placing a cross in the box:
* [ ] This is not a question (e.g. like one you might ask on [StackOverflow](http://stackoverflow.com)) and I have searched StackOverflow for discussions of this issue
* [ ] This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to [the compiler and tooling repository](https://github.com/dotnet/fsharp)
* [ ] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it
* [ ] I have [searched both open and closed suggestions on this site](http://github.com/fsharp/fslang-suggestions/issues) and believe this is not a duplicate

Please tick all that apply:
* [ ] This is not a breaking change to the F# language design
* [ ] I or my company would be willing to help implement and/or test this

## For Readers

If you would like to see this issue implemented, please click the :+1: emoji on this issue. These counts are used to generally order the suggestions by engagement.

Start by reviewing the proposed prototype record syntax and the existing class-based approach shown in the issue. No files, tests, or compiler entry points are identified; the work is done when prototype field lookup, inherited function parameters, and duplicate-name behavior have an agreed language design and corresponding implementation plan.

Written by the indexing model from the issue text.