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

Top-down programming support #778

Open
goldimax opened this issue Aug 28, 2019 · 8 comments

Comments

@goldimax
Copy link

commented Aug 28, 2019

Top-down programming support

(Sorry for my poor English writing)

As the complex let binding is hard to read, it’s common to refactor with let binding inside the previous binding. Just like this:

let calc arg1 arg2 =
    let x = ...
    let y a = ...
    let z a b =
        let q c = ...
        ...
    ...

But if the let binding body is really really long, it’s hard to find the main expression of the let binding immediately. You need to scroll and scroll. If there is a top-down key word, it would be easier to read. I give a example here using where as keyword.

let calc arg1 arg2 = ...
    where z a b = ...
        where q c = ...
    where y a = ...
    where x = ...

Thus, the main expression is placed just after the let definition. Just read the first line of the binding to know what it returns. Also, with the top-down keyword we can write a function from top to the bottom. Just write the main expression and then write what the dependencies. It’s obviously that human does better on destruction than construction. So it’s easier to write & read functions this way.

Extra information

Estimated cost: M

Affidavit (please submit!)

Please tick this by placing a cross in the box:

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • 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.

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

This comment has been minimized.

@goldimax

This comment has been minimized.

Copy link
Author

commented Aug 28, 2019

@orthoxerox Yeah, my friend told me that both Idris and Coq can do this.

@Happypig375

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

Visual Studio has collapsible code sections, you can collapse them if you wish to scroll faster.

@Happypig375

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

Also, you can use let ... and ... to write these.

let calc arg1 arg2 = ...
and z a b = ...
and q c = ...
and y a = ...
and x = ...

You just need to disable the warning about recursive objects on x.

@goldimax

This comment has been minimized.

Copy link
Author

commented Aug 28, 2019

@Happypig375 But let rec...and cannot catch the context and you can call the function defined by and. This idea is great but not enough.

@shawn-martin

This comment has been minimized.

Copy link

commented Aug 29, 2019

This is somewhat analogous to the requests to remove requirements for types being defined before being used and the knock-on effects on file order in F#. I like the current behavior. When learning Haskell and playing with Idris, the "where" syntax annoyed me. It's just another way to accomplish almost the same thing as let, but differently. I prefer the simplicity of "let" syntax only and I like that I know where to find the result of an expression every time without thinking (at the bottom). I'm curious to see if other people share this opinion.

@Happypig375

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2019

You can still collapse code blocks in Visual Studio.

@cartermp

This comment has been minimized.

Copy link
Member

commented Aug 30, 2019

This touches upon the following decision criteria:

whether this gives multiple ways to achieve the same thing

Which I think would rule this out unless there were more you could accomplish with it than you can today with inner let-bound functions. Though I know the pain of large functions with many inner functions declared within, I doubt any alternative syntax for inner functions would be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.