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.

Sign up for GitHub

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

Jump to bottom

Removing Tuples Types? #537

Closed
DavePearce opened this issue Sep 12, 2015 · 3 comments
Closed

Removing Tuples Types? #537

DavePearce opened this issue Sep 12, 2015 · 3 comments
Assignees
@DavePearce
Labels
Question
Milestone
v0.3.38

Comments

@DavePearce
Copy link
Member

An interesting question is whether or not we can actually remove tuple types altogether. My reasoning for this is:

  1. Tuple types are an additional point of complexity. In particular, there is currently confusion over the parameters/return to a function and whether or not they should be a tuple. This has been largely a disaster in WyCS and I don't want to repeat that.
  2. Tuple types are not used that much. In general, tuple types are mostly used for multiple returns. Therefore, we can support multiple return values explicitly along with destructuring syntax whilst still getting rid of tuples.
  3. Tuples are useful, but records provide a good alternative. Although one of my big gripes with Java was the lack of support for tuples, part of the reason for this is that there is no lightweight alternative. In Whiley, record types are a light weight alternative which provide very little additional overhead compared with tuples. Hence, in the few cases we really want tuples, we can just use records instead.

To support this, I think it would be quite useful to examine the use of tuple types in my benchmarks and test cases.
@DavePearce DavePearce added this to the ChangeList Pre v0.4.0 milestone Sep 12, 2015
@DavePearce
Copy link
Member Author

From 0XX benchmark series, have the following observations:

  1. 006_queens uses a tuple (int,int)[].
  2. 009_lz77, 011_codejam, 012_cyclic use multiple return values.

In 006_queens the tuple is use to represent a position on the board:

type Pos is (int,int)

Realistically, this would be better anyway:

type Pos is {int x, int y}

@DavePearce
Copy link
Member Author

One of the big challenges here, however, is: what type to give functions which return multiple values?

A few points on this:

  1. Could retain tuple type specifically for this purpose. In this case, there would be no source-level syntax for the tuple type. However, this would then need to be at the WyIL level as well?
  2. Could have specific syntax for multi-assignment function/method invocations. Then we would update the invoke bytecode to support multiple assignment as well.

DavePearce added a commit that referenced this issue Jan 6, 2016
@DavePearce
Progress removing tuples #537
695e47e 
Have done a large amount of the leg-work to remove tuples.  This
includes removing the type from wyc, wyil and wyjc along with all
corresponding bytecodes and code generation, etc.  What remains is to
decide how to deal with the lack of type patterns.
DavePearce added a commit that referenced this issue Jan 6, 2016
@DavePearce
Progress removing tuples #537
cd17455 
Have done a large amount of the leg-work to remove tuples.  This
includes removing the type from wyc, wyil and wyjc along with all
corresponding bytecodes and code generation, etc.  What remains is to
decide how to deal with the lack of type patterns.
DavePearce added a commit that referenced this issue Jan 6, 2016
@DavePearce
Fix lots of problems after removing tuples #537
189b04c 
This fixes a lot of obvious problems related the handling of tuples, and
partially fixes the parser.  It looks likely that I will also require
return types to be bracketed, and to include names.
@DavePearce DavePearce self-assigned this Jan 6, 2016
DavePearce added a commit that referenced this issue Jan 7, 2016
@DavePearce
Continued removing tuples #537
64a853c 
Have continued and almost finished removing tuples.  Lots of problems
arose, including:

1) Have temporarily removed ability to handle multiple assignments

2) Have had to think about ordering of parameter and return registers in
WyIL.  This puts parameters first and then returns.

3) Have updated parser to disambiguiate assignments, variable
declarations and function invocations.

These changes will undoubtedly cause a lot of problems.
DavePearce added a commit that referenced this issue Jan 7, 2016
@DavePearce
Remove Tuples #537
6318038 
This patch removes the notion of a "tuple" from Whiley.  This has fairly
significant ramifications for the syntax of the language.  Notably:

1) Removal of tuples types, expressions and associated bytecodes.  In
particular, this means there is no longer a notion of a "tuple LVal".
This means that we lose support for "destructuring assignments".

2) Change syntax for multiple returns in functions/methods.  Previously,
multiple return values were handled at the Whiley source level using
"type patterns".  Now, instead, functions and methods have an internal
notion of "returns" instead of a single "return", largely similar to the
way that parameters are represented.  This also means that the way
registers are allocated at the WyIL bytecode level is adjusted so that
parameters take the first n slots, followed by m returns and then local
variables, etc.

3) Removal of "Type Pattern".  One of the advantages of losing tuples is
that we can basically remove the notion of a "Type Pattern" altogether.
However, this means that we've temporarily (at least) lost the ability
to do a rational destructuring assignment.  This needs to be resolved in
one way or another.

4) Return types are now required to be bracketed, and to include names.
This was previously something I was considering and now seems like a
good idea to drop it in.

These changes are non-trivial and more thought is required to properly
integrate them into the Whiley language.
DavePearce added a commit that referenced this issue Jan 10, 2016
@DavePearce
Remove Tuples #537
32b1d35 
This patch removes the notion of a "tuple" from Whiley.  This has fairly
significant ramifications for the syntax of the language.  Notably:

1) Removal of tuples types, expressions and associated bytecodes.  In
particular, this means there is no longer a notion of a "tuple LVal".
This means that we lose support for "destructuring assignments".

2) Change syntax for multiple returns in functions/methods.  Previously,
multiple return values were handled at the Whiley source level using
"type patterns".  Now, instead, functions and methods have an internal
notion of "returns" instead of a single "return", largely similar to the
way that parameters are represented.  This also means that the way
registers are allocated at the WyIL bytecode level is adjusted so that
parameters take the first n slots, followed by m returns and then local
variables, etc.

3) Removal of "Type Pattern".  One of the advantages of losing tuples is
that we can basically remove the notion of a "Type Pattern" altogether.
However, this means that we've temporarily (at least) lost the ability
to do a rational destructuring assignment.  This needs to be resolved in
one way or another.

4) Return types are now required to be bracketed, and to include names.
This was previously something I was considering and now seems like a
good idea to drop it in.

These changes are non-trivial and more thought is required to properly
integrate them into the Whiley language.
DavePearce added a commit that referenced this issue Jan 13, 2016
@DavePearce
Remove Tuples #537
8d14d05 
This patch removes the notion of a "tuple" from Whiley.  This has fairly
significant ramifications for the syntax of the language.  Notably:

1) Removal of tuples types, expressions and associated bytecodes.  In
particular, this means there is no longer a notion of a "tuple LVal".
This means that we lose support for "destructuring assignments".

2) Loss of "multiple returns" for functions or methods.  This is
something I may revisit in the future as I believe it's useful.  But,
for the moment, it remains a "nice to have".

3) Removal of "Type Pattern".  One of the advantages of losing tuples is
that we can basically remove the notion of a "Type Pattern" altogether.
However, this means that we've temporarily (at least) lost the ability
to do a rational destructuring assignment.  This needs to be resolved in
one way or another.

In addition, I have removed the concept of a "throws clause" from wyil
types altogether.
DavePearce added a commit that referenced this issue Jan 13, 2016
@DavePearce
Update test cases to match new syntax #537
ccfa3e9 
Many test cases used tuples, and were failing after tuples had been
removed.  These are now either deleted or reworked not to use tuples.
There are a small number which still fail for more fundamental reasons.
DavePearce added a commit that referenced this issue Jan 13, 2016
@DavePearce
Bug fixes related to removal of tuples #537
dd9a3e6 
These are a bunch of fixes which get almost all test cases passing,
finally.
This was referenced Jan 13, 2016
Closed
Closed
Closed
DavePearce added a commit that referenced this issue Jan 13, 2016
@DavePearce
Prevent reusing return variable in body #537
7c46187 
This fixes some outstanding problems related to the removal of tuples.
In particular, it prevents duplicate variable names between the return
type and the body of the function/method.
@DavePearce DavePearce mentioned this issue Jan 13, 2016
Closed
@DavePearce
Copy link
Member Author

Right, I'm closing this now as it's essentially now resolved. The remaining issues are split out separately into #566 (fields in invariants), #565 (multiple returns), #339 (flow typing field accesses), #552 (which should be reopened)

@DavePearce DavePearce mentioned this issue Jan 13, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@DavePearce DavePearce

Labels
Question
Projects
None yet
Milestone
v0.3.38
Development

No branches or pull requests
1 participant
@DavePearce