-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Discussion] Should we rewrite the project in F#? #111
Comments
Hi @ForNeVeR . At the moment this is a personal project and I am only asking for help to understand the existing code, before you have it documented. The project may fail because the code is too object oriented, I cannot simplify the cyclic dependencies and convert the existing structures which rely on mutability and inheritance. If it succeeds then there should be a linear structure (perhaps a discriminated union data structure for representing the formula structure, one for representing how it will be displayed, and then a rendering layer). It would make sense to have this discussion at that point, once you can see the F# code. If you like it you can decide whether to switch the project over, based of the affinity of F# vs C# for the task, likelihood of getting contributors, etc.. If you don't do that, no problem: I will keep the F# project separate. I do think that WPF is a likely to be a red herring but it will be a while before I get round to the rendering layer. |
@Nocturnals Your post disappeared, please repost! |
This is my Atom. I think that a LaTeX string should be parsable into one of these. Then a function can convert an Atom into a Box, which describes how to render it. Does that sound right? Code[<RequireQualifiedAccess>]
type Atom =
/// horizontal row of other atoms, separated by glue
| Row of Atom list
/// single character in specific text style
| Char of char * textStyle: string option
/// character that does not depend on text style
| FixedChar of c:char * fontId:int
/// base atom with accent above it
| Accented of Atom * Symbol
/// big delimeter (e.g. brackets)
| BigDelimiter of delimiter:Atom * size:int
/// big operator with optional limits
| BigOperator of baseAtom:Atom * upperLimit:Atom * lowerLimit:Atom
/// base atom surrounded by delimeters
| Fenced of baseAtom:Atom * leftDelimiter:Symbol * RightDelimiter:Symbol
/// fraction, with or without separation line
| Fraction of numerator:Atom * denominator:Atom // * nAlign:TexAlignment * dAlign:TexAlignment
/// other atom with horizontal rule above it
| Overlined of baseAtom:Atom
/// scripts to attach to other atom
| Scripts of baseAtom:Atom
/// whitespace.
| Space of width:float<mu> * height:float<mu>
/// other atom that is not rendered
| Phantom of baseAtom:Atom * useWidth:bool * useHeight:bool * useDepth:bool
/// other atom with custom left and right types
| Typed of atom:Atom * leftType:TexAtomType * rightType:TexAtomType
/// single character that can be marked as text symbol
| CharSymbol of isTextSymbol:bool
/// symbol (non-alphanumeric character)
| Symbol of name:char * TexAtomType * isDelimiter:bool
/// other atom with delimeter and script atoms over or under it
| OverUnderDelimiter of baseAtom:Atom * script:Atom * Symbol * kern:float<mu> * over:bool
/// other atom that is underlined
| Underlined of baseAtom:Atom
/// other atom with atoms optionally over and under it
| UnderOver of baseAtom:Atom * underOver:Atom * underOverSpace:float<mu>
/// other atom vertically centered with respect to axis
| VerticallyCentered of atom:Atom
/// radical (nth-root) construction
| Radical of baseAtom:Atom * degreeAtom:Atom
/// gets the types of the left and rightmost children or the type of the atom itself if it childless
member t.GetLR: TexAtomType * TexAtomType =
match t with
| Row x -> x.Head.GetLeftType, List.last(x).GetRightType
| BigDelimiter (a,_) | BigOperator (a,_,_) | Phantom (a,_,_,_) | Scripts a
-> a.GetLR
| Fenced (_,l,r) -> TexAtomType.Opening, TexAtomType.Closing
| Typed(_,l,r) -> l,r
| _ -> t.Type, t.Type
member t.GetLeftType = t.GetLR |> fst
member t.GetRightType = t.GetLR |> snd
member t.Type = ... |
Apart from the solid points you make, @ForNeVeR, I don't feel F# has gained enough traction generally to warrant a rewrite. It might get harder and harder to maintain. Writing components of it (like the testing, which we already do) would be no problem, however. |
@charlesroddie yes, that looks pretty much like I imagined. Seems like you're doing it right :) |
My 2c. I personally prefer C# for general purpose libraries, just make sure it works nicely for F# users too, i.e. no OOP-inheritance-based API, support for records/du and so on. |
@gsomix This can be achieved by a mixture of taking out the explicit OO aspects of the library and writing some thin shims for F#, I feel. |
Alright, I believe we've decided to not rewrite the project in F#. Thanks for the discussion! |
(I've decided to open new issue in answer to this comment from @charlesroddie: #43 (comment).)
@charlesroddie well, yeah, most (if not all) of the current contributors know F# and personally I am very positive about it (up to the point I actually contribute to F# compiler a little bit). Although I'm not sure if we actually want to rewrite the WPF-Math in F#, and here's why:
These're the reasons I still want to develop WPF-Math in C# and I'd prefer not to rewrite it in F#. Please understand my position: I'm not being closed for new technologies (in fact, it was me who decided to write the unit tests in F# here, and I prefer F# over C# in most of my personal projects these days), I'm just trying to be objective. I think that it'll be good for this project to be developed in C#. Although I'm open for discussion. If anyone have their own opinion: let's discuss!
/cc @alexreg @gsomix @Nocturnals @charlesroddie
(This discussion isn't limited to the project contributors; feel free to participate in it if you have something to say.)
The text was updated successfully, but these errors were encountered: