Python-like syntax with pattern matching and recursive ADTs!? What a great idea!
If you're looking for a more mature language that feels like that, I very much recommend scala.
Pyret: A new programming language from the creators of Racket
151–160 of 288 posts
Re: Pyret: A new programming language from the creators of Racket
#152Earlier quoted context omitted.
Pyret doesn't actually have an indentation-based format (so far as I know) it just happens to look like python.
That's correct. There is a preferred indentation (enforced by the emacs mode and our online editor built on CodeMirror), but whitespace is only needed to separate things - the actual amount of whitespace never matters. So, for example, you can move chunks of code from one place to another and select it all and re-indent - something that you can't do (in general) in Python. It also makes it easier to programatically g…
When you have both braces/keywords and whitespace, it seems to me that you're essentially storing the same information about the program structure in two places, of which one is read by the machine and the other is read by humans. The "re-indent" operation reads the master copy and updates the other one. (And if you forget to re-indent, your human readers will be interpreting an outdated copy and be very confused.)
In Python, on the other hand, the information only exists in one place: the indentation. This is read both my machines and humans. There is no "re-indent" operation as the indentation is the only place the information exists, so there is nothing to sync.
I have heard people bring up programatically generated code before, but as another commenter put it "where Ruby usually denotes code blocks with a `do` and an `end`, Python denotes code blocks with a `:` and an outdent" – so is that really a problem? Isn't it just a slightly different way of encoding the same information?
(As to moving chunks of code in the editor: If the editor has a command to re-indent a selected block, it probably also has a command to shift it left or right.)
Re: Pyret: A new programming language from the creators of Racket
#153Earlier quoted context omitted.
You can actually use ";" as an alias for "end" in Pyret, so you could write: data BinTree: | leaf | node(value, left, right); We use "end" or ";" in order to have unambiguous delimiters for the ends of syntactic forms and avoid needing to depend on whitespace (we added some discussion on pyret.org about our philosophy on indentation and why we don't want to depend on whitespace). Making that leading pipe optional is…
I realize it's a trade-off -- but I think having ";" as an alias for "end" (or vice-versa) is a pretty bad idea. I personally prefers python's indentation-for-blocks syntax, but I understand why you want semantics to be decoupled from indentation. But when using explicit end-markers, I'd prefer to match them to the start, maybe even introducing some verboseness, like: end-case, end-if etc -- maybe taking it further a…
Having ; on a new line is valid, but having both ; and end on a block is invalid.
Re: Pyret: A new programming language from the creators of Racket
#154Earlier quoted context omitted.
You can actually use ";" as an alias for "end" in Pyret, so you could write: data BinTree: | leaf | node(value, left, right); We use "end" or ";" in order to have unambiguous delimiters for the ends of syntactic forms and avoid needing to depend on whitespace (we added some discussion on pyret.org about our philosophy on indentation and why we don't want to depend on whitespace). Making that leading pipe optional is…
I realize it's a trade-off -- but I think having ";" as an alias for "end" (or vice-versa) is a pretty bad idea. I personally prefers python's indentation-for-blocks syntax, but I understand why you want semantics to be decoupled from indentation. But when using explicit end-markers, I'd prefer to match them to the start, maybe even introducing some verboseness, like: end-case, end-if etc -- maybe taking it further a…
I have wrestled with "uniform closing" vs "non-uniform closing" designs for ages. For those not clear on what I mean here's an example: Lispy syntaxes have a uniform close (it's always ")"), whereas XML syntaxes don't (you have to put the name of the opening tag in the closing token).
So e12e is making an argument for XML-y over Lispy. However, choosing good words is really, really hard. If you pick a different word for each construct, there's a needless mental burden; if you pick a uniform strategy ("end-") you potentially get less readable code. And either way it's far more verbose, as you point out.
Some of our target audiences are middle- and high-school students, some of whom have weak typing skills (we know from numerous workshops we run). Increasing even the raw number of characters is a real problem for them.
My preference is to use ; for one-liners, but end where you have a multi-clause entity and you want to be able to clearly tell where it ends. If we find that there is general agreement on this, we can make it a context-sensitive check, à la indentation. Then, a program generated by a tool can do something consistent and ignore all these checks, whereas human-facing environments would enforce them (by checking or correcting).
As for your examples, to my Pyretical eye, the third of your examples (with the dangling ";") looks just wrong. However, your fourth example is syntactically incorrect.
Re: Pyret: A new programming language from the creators of Racket
#155This project seems really promising, but I got one concern. Lisp's syntax have been one of its strength for beginners. Easy to learn, easy to solve common errors. I don't see the point of having Python-like syntax really, the user could learn other syntax after they've understood programming .
Syntax is tricky and contentious, and our team members do love our Schemes. Members of the Pyret team have actually done some research on the issue of parenthetical expressions in introductory programming, and seen that parens aren't necessarily the best: http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-va... One issue is that it's too regular: since open-paren means so many different things (start of a "def…
Did you ever do any research/tests/courses with Smalltalk as the first language?
Re: Pyret: A new programming language from the creators of Racket
#156Earlier quoted context omitted.
At the other end are definitions of which several fit on a single line: data Color = Red | Black
Lines really aren't much of a thing: they are a single keypress, which generates a newline character and some autogenerated indentation from your editor. There's no real difficulty in breaking things up across two lines versus typing any other extra character (this touches on another issue, which is that I am of the opinion that the concept of code brevity estimation by line count comparison is fundamentally flawed,…
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
I'm confused: y is defined twice
The goal here is to make the common case work fine, where you create a bunch of distinct local bindings; but when you try to mutate, you have to do it explicitly:
fun f(x):
var y = x * x
y := x + 2
x - y
where:
f(10) is -2 # the test passes
end
Re: Pyret: A new programming language from the creators of Racket
#157Earlier quoted context omitted.
Sounds like Eiffel: http://en.wikipedia.org/wiki/Eiffel_(programming_language)#D...
Not even remotely in just about any respect.
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.
Re: Pyret: A new programming language from the creators of Racket
#158Mostly OT: I've been working on the spec for a lang I'd like to implement at some point and would like feed back if anyone cares to give any?
Re: Pyret: A new programming language from the creators of Racket
#159Somehow, it looks a lot more like lua with a bunch of type-checks and tests added then like python. No named parameters, no generators, no comprehensions that I can see, no focus on iteration in general, no significant indentation, etc. Instead: "end" syntax, unified number type, all blocks produce new scopes (not just functions), local variables are explicit instead of default, etc.
Indeed, but apparently, it doesn't have multiple return values, and I don't know if there is an equivalent to metamethods.
It's easy to obtain the equivalent of multiple return values by using a literal object.
I've been burned by multiple return values numerous times in Scheme and Racket. They're very subtle and hard to make performant. It's one of those language features that very much does _not_ pay its own way, so you have to really, really need it to want to put it in your language. My view is that its uses are not many, and most (all?) can easily be achieved with literal objects. That's why Pyret doesn't have them and is unlikely to get them.
Re: Pyret: A new programming language from the creators of Racket
#160Python-like syntax with pattern matching and recursive ADTs!? What a great idea!
If you're looking for a more mature language that feels like that, I very much recommend scala.
Scala is statically typed through-and-through. Pyret is designed to always offer a dynamic account of the language. We do have a static type checker under development (it's all-but-ready to release), but it will always work over a language where type annotations are optional. We also have a radically different idea about type inference, which we are currently trying out. In short, Pyret and Scala are already quite different and will grow even more so soon.