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

Maybe types and tuples don't get printed properly. #352

Closed
TheGrandmother opened this issue Mar 21, 2016 · 2 comments · Fixed by #380
Closed

Maybe types and tuples don't get printed properly. #352

TheGrandmother opened this issue Mar 21, 2016 · 2 comments · Fixed by #380
Assignees
@EliasC
Milestone
April'16 Sprint

Comments

@TheGrandmother
Copy link
Contributor

when using formatted printing to print Maybe types and tuples only the address is returned.
This makes debugging and testing quite annoying if one has to match every time one wants to print.

The following code:

print("{}\n",Nothing);
print("{}\n",Just 1);
print("{}\n",(1,2,3,4))

returns:

0x61a730
0x7f31dc4d2140
0x7f31dc4d2180

Which might not be super desirable.
@PhucVH888
Copy link
Contributor

It looks similar to issue #320

@TobiasWrigstad TobiasWrigstad added this to the April'16 Sprint milestone Apr 14, 2016
@EliasC EliasC mentioned this issue Apr 15, 2016
Merged
albertnetymk pushed a commit that referenced this issue Apr 18, 2016
@EliasC @albertnetymk
Improved printing support (#380)
52dc242 
This commit improves the printing support and fixes #352 and fixes #320.
The following list summarizes the current printing behavior:

* Reference types `T` are printed as `T@0x012345`, where the hexadecimal
  value is the address of the object. The same thing goes for futures,
  streams, arrays, ParTs and closures. `null` is printed as `T@0x0`.

* Values whose type isn't statically known cannot be printed. This
  includes any polymorphic values.

* Values of embedded types cannot be printed. You can (and should) drop
  down to C if you really need to print such a value (or closures or
  polymorphic values for that matter).

* Ranges are printed as `[1..10 by 1]`. The `by` part is always included
  for simplicity.

* Maybe types are printed like they should, although the generated code
  is a bit nasty. For each maybe type, a string is allocated for the
  sole purpose of being printed. The length of this string is
  approximated by summing approximations of the lengths of all
  subexpressions. Strings use their dynamic lengths and tuples the sum
  of the approximations of their contents. All other lengths are
  approximated as the length of their type plus 30 (compare with how
  reference types are printed). The 30 should be enough to hold any
  addresses, integers or reals. It would be better to calculate a
  maximum depending on the type, but if you're doing things like
  printing `Maybe`s, you probably don't care about performance anyway.

* Tuples are also printed like they should, and since their shape is
  known statically, the code isn't as bad.

* Values of `void` type are always printed as `()`

* Strings, chars, ints, booleans and reals are printed like you would
  expect. The only news here is proper printing of booleans as `true`
  and `false`.

The existing tests already test much of the printing, and some of them
have been updated to align with the new syntax. The test `printf` tests
some of the new printing.

Testing this has reminded me that the lack of proper inference for
`null` and `bottom` is annoying, but fixing this does not belong in this
PR.
@EliasC
Copy link
Contributor

EliasC commented Apr 21, 2016

Fixed by #380

@EliasC EliasC closed this as completed Apr 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@EliasC EliasC

Labels
None yet
Projects
None yet
Milestone
April'16 Sprint
Development

Successfully merging a pull request may close this issue.

Improved printing support
4 participants
@TobiasWrigstad @EliasC @TheGrandmother @PhucVH888