Incidentally, a Gist for installing Pyret using Marelle:
Pyret: A new programming language from the creators of Racket
281–288 of 288 posts
Re: Pyret: A new programming language from the creators of Racket
#282Earlier quoted context omitted.
An express design goal is to not bake in assumptions about an editor. Programmers really like their editing tools. I've lived through the waves from vi to Emacs to vim to Sublime Text to what-have-you. We'd really, really like to make the language pleasing to work with without depending on an editor (indeed, each of us seems -- perhaps by accident -- to be using a different editor for Pyret, which may be influencing…
Your point about programmers having favourite editors (which I consider valid) contradicts the point you made about an important part of your audience being middle/high schoolers, which I don't think have such strong preferences towards one editor or another. It seems to me that you are making compromises to cater to the needs of an audience which is much broader than that you have identified for the language. It wou…
I have many target audiences. I mentioned middle- and high-schoolers in response to various other questions, but I don't anticipate them being the largest audience. I expect the biggest audiences to be introductory college-level education and second/third-year courses on "paradigms" (blecch) that want a flexible language to illustrate several concepts. Finally, I am also consciously building a language and book to appeal to the working programmer who has not learned to think of computation as primarily producing values, and would like to quickly get up to speed with that idea.
All of these are educational audiences. I don't see how one can define the audience more clearly than that, given that I have no control over any of these audiences.
Re: Pyret: A new programming language from the creators of Racket
#283Earlier quoted context omitted.
I can't respond directly to e12e's comment ("Please don't use equal for assignment" -- https://news.ycombinator.com/item?id=6704229 ) so I'll slightly abuse responding by doing so at this level. We don't EVER use = for assignment. For us, = is binding. If you write fun f(x): y = x * x y = x + 2 x - y end Pyret will say I'm confused: y is defined twice and point to the two bindings. The goal here is to make the common…
Thank you for distinguishing bindings and assignments. Please consider `var y := x * x` for consistency (note the ':=').
We considered it and decided against it for a few reasons.
- We want := to mean "change". The initial binding is not a change. This is precisely the "bindings and assignments" distinction you're talking about.
- A variable may in fact not be mutated.
- A small point is that we want to localize editing when making a change.
So, the way I read
var y = x * x
y := x * z
So: "=" means "introduced a name with this value"; "var" means "but this binding may change"; ":=" means "and yup, it really _did_ change".
Re: Pyret: A new programming language from the creators of Racket
#284Earlier quoted context omitted.
I can't respond directly to e12e's comment ("Please don't use equal for assignment" -- https://news.ycombinator.com/item?id=6704229 ) so I'll slightly abuse responding by doing so at this level. We don't EVER use = for assignment. For us, = is binding. If you write fun f(x): y = x * x y = x + 2 x - y end Pyret will say I'm confused: y is defined twice and point to the two bindings. The goal here is to make the common…
Thank you for distinguishing bindings and assignments. Please consider `var y := x * x` for consistency (note the ':=').
We considered it and decided against it for a few reasons.
- We want := to mean "change". The initial binding is not a change. This is precisely the "bindings and assignments" distinction you're talking about.
- A variable may in fact not be mutated.
- A small point is that we want to localize editing when making a change.
So, the way I read
var y = x * x
y := x * z
So: "=" means "introduced a name with this value"; "var" means "but this binding may change"; ":=" means "and yup, it really _did_ change".
Re: Pyret: A new programming language from the creators of Racket
#285Earlier quoted context omitted.
I can't respond directly to e12e's comment ("Please don't use equal for assignment" -- https://news.ycombinator.com/item?id=6704229 ) so I'll slightly abuse responding by doing so at this level. We don't EVER use = for assignment. For us, = is binding. If you write fun f(x): y = x * x y = x + 2 x - y end Pyret will say I'm confused: y is defined twice and point to the two bindings. The goal here is to make the common…
Thank you for distinguishing bindings and assignments. Please consider `var y := x * x` for consistency (note the ':=').
We considered it and decided against it for a few reasons.
- We want := to mean "change". The initial binding is not a change. This is precisely the "bindings and assignments" distinction you're talking about.
- A variable may in fact not be mutated.
- A small point is that we want to localize editing when making a change.
So, the way I read
var y = x * x
y := x * z
So: "=" means "introduced a name with this value"; "var" means "but this binding may change"; ":=" means "and yup, it really _did_ change".
Re: Pyret: A new programming language from the creators of Racket
#286Earlier quoted context omitted.
Really? The concept of a block that specifies a contract does not sound similar to the design by contract capabilities of Eiffel. Care to enlighten us why not? Perhaps you think I was referring to something other than the quote in the comment I replied to.
Contracts are fundamentally different from tests. Contracts are abstract specifications about values while tests are concrete specifications about values. The concrete vs abstract distinction is fundamental, as I hope is clear. That's why Pyret has both tests and contracts (for now, in the form of refinements). This is a distinction that has been explored extensively in Racket also, all fully aware of Eiffel DBC.
Those refinements are nice. Pre- and Post- conditions are illustrated, is there any way to describe an invariant?
Also, maybe you should have called them something else since a lot of people will think about completely different when they hear this word... (http://www.ruby-doc.org/core-2.0.0/doc/syntax/refinements_rd...)
Re: Pyret: A new programming language from the creators of Racket
#287Earlier quoted context omitted.
Contracts are fundamentally different from tests. Contracts are abstract specifications about values while tests are concrete specifications about values. The concrete vs abstract distinction is fundamental, as I hope is clear. That's why Pyret has both tests and contracts (for now, in the form of refinements). This is a distinction that has been explored extensively in Racket also, all fully aware of Eiffel DBC.
Those refinements are nice. Pre- and Post- conditions are illustrated, is there any way to describe an invariant? Also, maybe you should have called them something else since a lot of people will think about completely different when they hear this word... ( http://www.ruby-doc.org/core-2.0.0/doc/syntax/refinements_rd... )
re: refinements nomenclature...
Rebol got there first though! - http://www.rebol.com/r3/docs/datatypes/refinement.html
Matz is known to like Rebol - https://twitter.com/matz_translated/status/25061436079433318...
Re: Pyret: A new programming language from the creators of Racket
#288Earlier quoted context omitted.
Can you say more about how multiple return is "very subtle and hard to make performant" and leads to getting burned? As far as I can tell the main advantage of multiple-return over literal objects is that callers who only care about the primary value can call the function the normal way, whereas if it's wrapped in an object they have to "pay" for it by explicitly extracting it. That's a nice-to-have but you seem to b…
1. Designing a performant multiple return values mechanism is very subtle. For instance, see J. Michael Ashley, R. Kent Dybvig: An Efficient Implementation of Multiple Return Values in Scheme. LISP and Functional Programming 1994: 140-149. 2. Write me the identity function. (No, really. Stop. Try. Then read on.) . . . . . I hope you didn't say it's fun id(x): x; because if F returns multiple values and G consumes the…
> 2. Write me the identity function. (No, really. Stop. Try. Then read on.)
In Lua:
function id(...) return ... end
a, b = id(1, 2) --> a == 1, b == 2
c, d = id(3) --> c == 3, d == nil
e = id(4, 5, 6) --> e == 4, the rest is discarded.
The vararg system is built on a stack mechanism, and it is efficient.
Regarding map and other higher level functions, I'd only take the first return value.
If you have tuples it is indeed less of a concern. Better still if you have destructuring assignement, à la Julia.