Some updates

[Joe Gibbs Politz]

Hi everyone!

A few updates on the codebase and language:

You may have noticed last night that there were just a few hundred commits
added to master. Several different things we've been building on the "horizon"
branch are now being migrated to code.pyret.org. Though it's a significant
increment, this isn't yet the final stable release for the summer, so we'll be
announcing other improvements and pointing out things that have changed in
upcoming weeks.

First and foremost, we finally got the new module system to the point where it
could bootstrap the compiler and work well propagating type information across
modules. I've written up a brief wiki article to describe why this matters:

https://github.com/brownplt/pyret-lang/wiki/TM014-----Module-Loading

Not much of this surfaces to users of Pyret _yet_; it mostly enables things on
the backend and gives us a much happier and consistent platform to build on.
This is now what main Pyret runs on, which is good news, and if you've been
tracking Pyret development, this is a big backend change.

There are several other significant improvements and additions; we'll be
detailing each in a separate message over the next few days, in order to
avoid a really long message and a single megathread.

There are a few significant added features:

* Error messages have been significantly reworded, reworked, restyled, and
improved.
* The type-checker is available via a drop-down menu next to the Run button.
It is still in beta, but we want folks to try it out and give feedback.
* "TODO", AKA templating expressions have been added.
* A new shorthand for anonymous functions has been added.
* Tuples have been added as a new kind of value, with some initial support for
destructuring assignment.
* code.pyret.org now has an "Open" button for accessing files and images.

There are also a few minor changes to the language that can break somewhat
esoteric programs:

* Method-declaration syntax has changed slightly
* Explicit `block` markers have been added to syntactically distinguish
multi-expression from single-expression blocks
* ";" is no longer a synonym for "end"

Happy programming,
The Pyret Crew

[Hilmar Hoffmann]

Oh, wonderful!

[Shriram Krishnamurthi]

Hi Yanyan!

Thanks for your interest.

The type-checker in Pyret requires that you provide type annotations:

that's just how it works. (If you know what "type inference" is,

that's not quite how Pyret works, though there is an inference mode

being created for it now.)

The language of types is just the same[*] as the language of

annotations that is already featured in PAPL. Thus, for instance, in

your function, the only thing you need to change is to change the

first line to be the following:

  fun hours-to-wages(hours :: Number) -> Number:

Everything else stays the same, and this program type-checks. This

says that `hours` has to be a `Number`, and the function itself also

returns a `Number`.

If you change it to

  fun hours-to-wages(hours :: String) -> Number:

you will get a type error; likewise if you change it to, say,

  fun hours-to-wages(hours :: Number) -> Boolean:

Note that you don't always have to write the return type of a

function; you could just have written

  fun hours-to-wages(hours :: Number):

and Pyret can "calculate" that the return type is `Number`. If, for

instance, you then wrote

  if hours-to-wages(10):

    "yes"

  else:

    "no"

  end

(which treats `hours-to-wages` as a Boolean-producing function), you

will get a _type_ error saying that it got a Number where a Boolean

was expected — thereby confirming that Pyret "inferred" that

`hours-to-wages` produces a `Number` even though you didn't formally

say so.

Hope this helps? I know the error messages are not terrific, which is

why it's marked as a beta release…

Shriram

[Yanyan]

Hi Shriram, thanks for the explanation! 

Sorry I just deleted my post, because I found the chapter about type-inference and thought it answer my questions. 

Now I see that type-inference and type-checking are not the same thing, I guess I should paste my original post here:

For Type-check and Run button, now it's asking for type annotation for functions. Is it necessary? If so, is there a chapter in PAPL or Pyret documentation explaining why we want/need type annotation for functions?

 

- answer: related reading from PAPL about type-inference: http://papl.cs.brown.edu/2014/Type_Inference.html

Take the hours-to-wage example at the beginning at PAPL. I could write a program like this and it runs fine:

fun hours-to-wages(hours):
  if hours <= 40:
    hours * 10
  else if hours > 40:
    (40 * 10) + ((hours - 40) * (10 * 1.5))
  end
end

But I'll get this error if I try Type-check and run:
The argument at fun hours-to-wages(hours): needs a type annotation.

Yanyan

[Shriram Krishnamurthi]

Correct. I didn't want to burden you with a whole PAPL chapter, but you've done that to yourself (-:.

Though the way type inference will work in Pyret is very different; it will be an algorithm on top of the current type-checker, so in the end a conventional type checker will still run. We're excited about the progress we're making on it (where "we" here is really Matthew Kolosick, who is also responsible for the type-checker, with lots of work by Jack Wrenn on the error message display).

When that's done, I'll have to rewrite that chapter of PAPL. (-:

Shriram

--

You received this message because you are subscribed to the Google Groups "Pyret Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyret-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.