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

Need import #119

Open
JacquesCarette opened this issue Nov 23, 2017 · 6 comments
Open

Need import #119

JacquesCarette opened this issue Nov 23, 2017 · 6 comments
Assignees

Comments

@JacquesCarette
Copy link
Contributor

PR #117 could be made better, and so would issue #96 if we had import working. There has been much discussion [but apparently never recorded here? Just in the mailing list?] about how to do this.

@zaxtax
Copy link
Member

zaxtax commented Nov 28, 2017

From my own notes from chatting with @ccshan about this suggest whatever solution we have provide

  1. Capture-avoiding substitution

I don't know if that is the right term. Basically baz.hk should work.

# foo.hk
normal <~ uniform(0, 1)
# bar.hk
y = normal(0,1)
# baz.hk
import foo
import bar

x <~ y
return (x + normal)
  1. Changes to the grammar to distinguish declarations from expressions

@JacquesCarette
Copy link
Contributor Author

Isn't normal already defined, so that foo.hk should, rather than 'work', return an error? I would consider it a bug, not a feature, if this worked!

If you were to rename normal to something else (like say z), then I would indeed expect baz.hk to work.

However, I do agree that import should be reasonably hygienic. Certainly if foo.hk defined something like y = uniform(0,1), then baz.hk should fail upon import of bar. I'm ok with shadowing for let, but shadowing across files that becomes order-dependent is a bad idea.

@zaxtax
Copy link
Member

zaxtax commented Jan 18, 2018

So something like foo.hk does give me an error, but the following is a perfectly valid program

def sin(x real):
    cos(x)
sin(5)

I think we are in broad agreement, but we should be very clear and precise about what properties we
want and don't want the module system to obey.

@zaxtax
Copy link
Member

zaxtax commented Jan 18, 2018

One property I would like is that we have some way to inline definitions in different files so the simplifier be able to work across those boundaries.

@JacquesCarette
Copy link
Contributor Author

Why does redefining sin work? Why is that a good thing? Doesn't that just lead to much debugging pain for very little gain?

I purposefully avoiding using the word module. If we want a module system, then we're going to need to spend quite a bit more effort on it - likely more than is currently available.

Nevertheless, I do think we are generally in agreement. Definitely agree that I want to be able to inline definitions from different files.

@zaxtax
Copy link
Member

zaxtax commented May 29, 2018

Bumping to get feedback from @ccshan

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

No branches or pull requests

3 participants