ikigai-go / compiler

Ikigai compiler
MIT License
0 stars 0 forks source link

Side effects in modules #3

Open alfonsogarciacaro opened 5 years ago

alfonsogarciacaro commented 5 years ago

If we're going to follow an F#-like syntax I assume functions and values in the modules will look very similar. However, I think we shouldn't enforce top-down order for functions, only for values. We can solve this by doing a first pass were functions are put into scope before checking their bodies and a second pass where we put values into scope as they appear.

let multiply (x, i) =
   let mutable res = 0
   for j in range(0,i) do
       res = add(res, x) // Ok, we can reference a function that appears later

let add (x,y) = x + y

let a = b + 1 // Error, b has not been initialized yet
let b = 5

Now the question is about side-effects (like console.log("foo")) on the module level. In F# and JS you can do them at any point, which I don't like very much. I think there should an exclusive function or declaration for them. I also believe this declaration should go on the top of the file (right after import declarations) so it can be seen very quickly, but when compiled to JS is put to the bottom so it happens after all values are initialized. To enforce this semantics, we could call the declaration onload (I don't like main because this is file-based not for the whole app).

import { Foo } from "bar"

onload() =
   console.log("A is", a)

let a = 5

What do you think? @MangelMaxime @whitetigle

MangelMaxime commented 5 years ago

I think we shouldn't enforce top-down order for functions, only for values

I was asking myself the same question today. And I do agree with that if we think about it in a larger scope like bindings it makes sense. I know that we are speaking about function declaration and not types but sometimes we can use both to declare bindings in F#.

And because d.ts and JavaScript don't enforce top-down order it was a real pain point. And in the end, we end up making the module recursive and even like that it didn't solve all the case.

The problem with the side-effects proposition is that we can't easily debug the code... Often I do things like:

let myFunc x y = ...

printfn "%A" (myFunc 2 3)

So I am not really sure about the side-effects propositions. I don't know much about their usage and don't see the any arm with having them at any place.

alfonsogarciacaro commented 5 years ago

@MangelMaxime You mean quickly testing a function? Actually we could make this a language feature, I'd love to have something like Rust document tests.

MangelMaxime commented 5 years ago

You mean quickly testing a function?

Yes, even if I think a bit about it, in general, I never test function at the module level. It's always inside another function I think.

Actually we could make this a language feature, I'd love to have something like Rust document tests.

This would be awesome because it's ATM a big problem when writing documentation like Thoth.Json or Fulma. I need to set up another project which is using the API and then have Nacara executing the code and extracting the source code to include it in the documentation.

Or if you remember, in the past we created Fable plugin, then webpack plugin in order to do that etc. Which is a really hacky and unpleasant experience.