Connection discovery and IDE identifier resolving spec #349

mwu-tow · 2020-04-06T00:47:14Z

Pull Request Description

This PR describes language rules as I understand them in a scope necessary to implement proper connection discovery (#320). It covers general language rules (that are relevant) and assumptions and simplifications that IDE can currently make.

Also, a number of TODO notes are left for things that I don't understand yet or that haven't been clearly specified. They are not blocking the implementation for connections, rather something that we are allowed to fill out later.

Important Notes

Checklist

Please include the following checklist in your PR:

The documentation has been updated if necessary.
All code conforms to the Rust, Scala, Java or Haskell style guides as appropriate.
All code has been tested where possible.

farmaazon

And as I understand the only case where identifier in node "body" (expression, right-side assignment operator) is shadowed is only lambda currently, right?

farmaazon · 2020-04-06T07:45:03Z

docs/connections.md

+argument (lambdas are always unary) and the right-hand side is its body.
+Right-hand side, i.e. the lambda body, introduces its own scope.
+
+If the lambda is *not* introduced in what is already a pattern context, the `->`'s pattern introduces identifiers into the scope of the right-hand


I think you introduced pattern scopes, and pattern context is a term from some previous version of this doc.

iamrecursion

Added a bunch of comments. Happy to discuss any of it with you.

iamrecursion · 2020-04-09T15:02:45Z

docs/connections.md

+* shadow identifiers from nested scope with a new binding;
+* introduce new constraints on the identifiers from parent (or own) scopes.
+
+The same identifier may be bound multiple times in the same scope (overloading).


This is currently not supported outside the global scope. We have an agreement that methods can only be defined in the global scope, so this seems fine to me. If that design decision has changed please let me know.

Is it "currently not supported" as-in:

The language implementation doesn't support it but the language deisgn itself allows it (kind like missing feature)

Language doesn't allow this but we could? (just by relaxing some rule)

We won't allow this unless there's significant change in the design?

For now I've noted this as the current implementation limitation, can change if needed.

Currently it's a tentative 2. There are technical obstacles given the current way method lookup is performed in the interpreter, but also there would be some typechecking obstacles to doing it which I'm a little unclear on given I'm somewhat divorced from that work right now. The design currently forbids, it, and we'd have to solve these technical challenges to allow it.

iamrecursion · 2020-04-09T15:03:10Z

docs/connections.md

+It is allowed only for method overloads that differ in the type of the `this`
+parameter. This limitation may be relaxed in the future, if proper motivating use-cases are found.
+
+The identifier is always accessible scope-wide, both before and after the line


This isn't something that is (or can be) handled at the moment. Additionally, it doesn't make sense. The definition of the desugaring of monadic contexts (in terms of bind) introduces an ordering dependency. If we want to distinguish between expressions in Pure and lift those into mutually recursive let blocks, that is a whole other kettle of fish that will require the typechecker.

From what I've understood from Wojciech's description:

we don't support this in the near-term

eventually we want this to work (at least so language design assumes)

I've added the description to the document.
Basicallt to avoid out-of-order variable usage, special rewrite rule is used that relies on the fix function. (that tricky thing from Haskell that you likely understand better than me. )Its implementation is specific to the monadic context of the code block.

Yeah we definitely want it to work eventually, but this is very much eventually.

iamrecursion · 2020-04-09T15:04:46Z

docs/connections.md

+Some other constructs seemingly introduce scope (like function definitions) but
+this is because they are desugared into some construct that introduces scope (like lambdas).
+
+TODO: Consider if there are any special rules for signatures on definitions, or


The identifiers defined in a signature are available in the body of the function, and vice-versa.

The vice-versa part looks tricky to me and not consistent with other rules. But generally I want to defer specifying the type ascription (as it won't be implemented for a while), and focus on other parts of the language.
For now I just try to record more important design questions to be addressed.

That's fair.

And yes, it is tricky, but it's also necessary for the way we're planning on handling dependency in type ascription. We want the ability to be able to define a type function foo in the body that can then be used in the signature.

iamrecursion · 2020-04-09T15:10:10Z

docs/connections.md

+
+Details will follow with description of these operators.
+
+// TODO What about `case … of` ? Are there any other pattern-introducing constructs?


The scrutinee of a case expression is not a pattern context, but the left hand side of the battern branches is.

iamrecursion · 2020-04-09T15:16:23Z

docs/connections.md

+```
+
+Therefore, only `value` will be introduced into the parent scope. `Some` and
+`get_opt` must be defined, the former being an atom with at least single field.


You should explain why you say "at least" here.

My understanding is that the language allows matching constructors with "missing" trailing fields. (as if there were arbitrary needed number of _ following)
I've clarified, though it gets little beyond the scope of this document.

iamrecursion · 2020-04-09T15:24:08Z

docs/connections.md

+
+TODO: Open question: does empty type (`Void`) exists in the language?
+
+TODO signatures and their relation with scoping. Difference for root and


Can you expand on this?

The example below shows some questions. Other were mentioned before, e.g. how and why scoping for identifiers introduced in a signature works for the body and vice-versa. Likely that should be a consequence of some more generals rules and desugaring.

I see what you mean. I think I've addressed it with other comments, but let me know if things are unclear.

iamrecursion · 2020-04-09T15:24:59Z

docs/connections.md

+  will be unified with other uses of `a` in other definitions.
+* or, actually, we want this to happen only in the root scope. When in
+  definition body, the `a` actually should be unified between signatures.
+  Doesn't sound that clean though.


Not clean at all.

iamrecursion · 2020-04-09T15:26:21Z

docs/connections.md

+  Doesn't sound that clean though.
+* Does argument-introduced `a` shadows the signature-introduced `a`?
+
+TODO: `b:A` — does this add constraint to `a` or just `b` ? 


Complex question of inference that can't easily be answered at this stage given how nebulous the type system is. Does it matter for the purposes of IDE right now?

Not at all. We disregard all type ascriptions for now.
But since I've created a section for them, I thought it was something worth asking.

iamrecursion · 2020-04-09T15:26:51Z

docs/connections.md

+IDE can assume that all extension methods will be introduced using the
+`Type.name` syntax sugar.
+
+// TODO what if non-first argument is named `this` ? Is the magic happening only


It is an error to define this at any position other than the first in the argument list.

iamrecursion · 2020-04-09T15:27:08Z

docs/connections.md

+
+// TODO what if non-first argument is named `this` ? Is the magic happening only
+for this particular name? Is it sensitive for its position in the arguments list?
+// TODO What happens if the `this`-taking function in defined in the root scope


This will also be an error.

…into wip/mwu/aliasing-doc

iamrecursion · 2020-04-14T09:51:08Z

docs/connections.md

+
+## Out of order variable usage in block
+If within a block an identifier is used in the line before it is assigned, the
+`fix` function appropriate for the block's monadic context will be introduced.


I don't know how performantly we can do this without a typechecker. The implementation doesn't currently support it, and I'll need to talk to Marcin about it when he's back.

farmaazon · 2021-04-15T09:47:33Z

@iamrecursion could you please look at this document again? It was written before removing UFCS and likely outdated in many places.

wdanilo · 2021-06-02T01:19:43Z

What is the status of this ?

farmaazon · 2021-06-02T09:20:14Z

What is the status of this ?

It waits for @iamrecursion after-UFCS-check. See my comment above. And because we have other priorities right now, it seem properly frozen in icebox.

mwu-tow added 6 commits April 2, 2020 04:00

first draft, wip

7671e44

wip

e5de56a

[wip]

e5c6f0e

updates

0840f81

done one more pass

00f6739

typos

77506c5

mwu-tow requested review from wdanilo and farmaazon April 6, 2020 00:47

mwu-tow self-assigned this Apr 6, 2020

mwu-tow added this to the Sprint 2020-03-30 milestone Apr 6, 2020

farmaazon approved these changes Apr 6, 2020

View reviewed changes

mwu-tow added 2 commits April 8, 2020 13:08

cr feedback, minor fix

9d2c6b8

Merge branch 'master' into wip/mwu/aliasing-doc

8546c0a

iamrecursion reviewed Apr 9, 2020

View reviewed changes

mwu-tow added 2 commits April 10, 2020 01:07

updates based on Ara's feedback and call with Wojciech

1189e26

Merge branch 'wip/mwu/aliasing-doc' of https://github.com/luna/basegl …

be7bbcb

…into wip/mwu/aliasing-doc

iamrecursion reviewed Apr 14, 2020

View reviewed changes

mwu-tow mentioned this pull request Apr 15, 2020

[WIP] Second checkpoint for alias analysis #359

Closed

3 tasks

iamrecursion changed the base branch from master to main June 15, 2020 17:53

farmaazon removed the Change: Non-Breaking label Dec 3, 2020

Base automatically changed from main to develop February 2, 2021 05:08

farmaazon requested a review from iamrecursion April 15, 2021 09:45

MichaelMauderer marked this pull request as draft September 16, 2021 16:47

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Connection discovery and IDE identifier resolving spec #349

Connection discovery and IDE identifier resolving spec #349

mwu-tow commented Apr 6, 2020

farmaazon left a comment

farmaazon Apr 6, 2020

iamrecursion left a comment

iamrecursion Apr 9, 2020

mwu-tow Apr 9, 2020

iamrecursion Apr 14, 2020

iamrecursion Apr 9, 2020

mwu-tow Apr 9, 2020

iamrecursion Apr 14, 2020

iamrecursion Apr 9, 2020

mwu-tow Apr 9, 2020

iamrecursion Apr 14, 2020

iamrecursion Apr 9, 2020

mwu-tow Apr 9, 2020

iamrecursion Apr 9, 2020

mwu-tow Apr 9, 2020

iamrecursion Apr 9, 2020

mwu-tow Apr 9, 2020

iamrecursion Apr 14, 2020

iamrecursion Apr 9, 2020

iamrecursion Apr 9, 2020

mwu-tow Apr 9, 2020

iamrecursion Apr 9, 2020

iamrecursion Apr 9, 2020

iamrecursion Apr 14, 2020

farmaazon commented Apr 15, 2021

wdanilo commented Jun 2, 2021

farmaazon commented Jun 2, 2021


		Details will follow with description of these operators.

		// TODO What about `case … of` ? Are there any other pattern-introducing constructs?


		TODO: Open question: does empty type (`Void`) exists in the language?

		TODO signatures and their relation with scoping. Difference for root and

Connection discovery and IDE identifier resolving spec #349

Are you sure you want to change the base?

Connection discovery and IDE identifier resolving spec #349

Conversation

mwu-tow commented Apr 6, 2020

Pull Request Description

Important Notes

Checklist

farmaazon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iamrecursion left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

farmaazon commented Apr 15, 2021

wdanilo commented Jun 2, 2021

farmaazon commented Jun 2, 2021