Skip to content
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

Closed
ForNeVeR opened this issue Jan 28, 2018 · 8 comments
Closed

[Discussion] Should we rewrite the project in F#? #111

ForNeVeR opened this issue Jan 28, 2018 · 8 comments
Assignees

Comments

@ForNeVeR
Copy link
Owner

ForNeVeR commented Jan 28, 2018

(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:

  1. WPF is a very C#-centric technology. One could use WPF with F# (and I had a couple of WPF projects in F#), but the experience is far from "native". Writing a WPF project in F# will create some (solvable) technical difficulties.
    • Yes, we're slowly moving towards cross-platform world, and we have plans to add support for some technologies alternative to WPF (SkiaSharp, Avalonia), although I think that WPF stuff (or maybe UWP, who knows?) will be a major part of our code for a long time from now.
  2. It means that we could expect most of the contributors to a WPF library to be familiar with C#. The same cannot be said about F#, sadly. Yes, we're in an interesting position here, because WPF-Math is a project for LaTeX specialists (mainly scientists I think), and they seem to be, let's say, more open-minded than "ordinary" WPF developers. Although I still think that knowing F# will be a barrier for potential contributors. And I love contributors who help me to develop the project, and I hate creating any barriers for them.

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.)

@charlesroddie
Copy link

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.

@charlesroddie
Copy link

@Nocturnals Your post disappeared, please repost!

@charlesroddie
Copy link

charlesroddie commented Jan 30, 2018

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 = ...

@alexreg
Copy link
Collaborator

alexreg commented Jan 30, 2018

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.

@ForNeVeR
Copy link
Owner Author

@charlesroddie yes, that looks pretty much like I imagined. Seems like you're doing it right :)

@gsomix
Copy link
Collaborator

gsomix commented Feb 2, 2018

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.

@alexreg
Copy link
Collaborator

alexreg commented Feb 2, 2018

@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.

@ForNeVeR
Copy link
Owner Author

Alright, I believe we've decided to not rewrite the project in F#. Thanks for the discussion!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants