functions are fun
Pyret: A new programming language from the creators of Racket
241–250 of 288 posts
Re: Pyret: A new programming language from the creators of Racket
#242Earlier quoted context omitted.
I don't see any difficult semantics in those examples. The hard part of parsing Ruby is mostly trying to conform to MRI rather than to a formal grammar. In comparison the semantics are reasonably simple. It's hard to compile Ruby efficiently , though, but for reasons unrelated to those examples. (Incidentally I don't know if that scoping example is intentionally ignoring the fact that Ruby does support lexical scopin…
> Incidentally I don't know if that scoping example is intentionally ignoring the fact that Ruby does support lexical scoping (EDIT: for blocks), or if it's lack of understanding of what what "def" is I also don't think it is fair to say that ruby "failed to nail lexical scope in fundamental ways". I like how it enables lexical scoping with blocks, instead of enabling it in, maybe, more common way with embedded funct…
I've done a fair amount of programming in Ruby (two reasonably large Rails applications, spanning about two years of development time). When switching to Ruby from just about anything else that I program in from JavaScript to Python to Racket to ML, I get tripped up on exactly this issue because it doesn't match my expectations at all.
My gripe is that the simplest, cleanest construct in the language for defining named functional abstractions---"def"---doesn't support closing over variables, which other languages do, so I have to warp my thinking a bit to program in Ruby. The analogous program in the four languages I mentioned above (and Pyret, and more) works and creates a closure. Maybe I just don't think well in Ruby, because I end up feeling frustrated that Ruby seems to not like functions.
All that said, "in fundamental ways" is a little harsh. At least in this example, Ruby hasn't done anything to violate the integrity of static scoping the way, say, JavaScript's "with" does. I'll try to see if I can come up with a better example that's a clearer problem and less a personal dislike.
Re: Pyret: A new programming language from the creators of Racket
#243Earlier quoted context omitted.
> Making tests part of language syntax is an interesting idea. It's been tried many times before and it has always failed. A few reasons: - It clutters the code - If you need simple tests, asserts suffice - If you need more sophisticated tests, write functional tests, separately The approach offered by Pyret (along with similar ones, such as design by contract) are compromises that are the worst of both worlds.
It's actually widely used in Racket already. Yesterday a lead programmer at a major financial institution told me that he liked that style so much, he'd incorporated it into his company's OCaml system, and they use it in their production systems (lots of high-volume trading). Hardly "failure"s. Nevertheless, perhaps you could provide some pointers to the "many" projects that have tried it before? Assertions are not t…
> Yesterday a lead programmer at a major financial institution told me that he liked that style so much, he'd incorporated it into his company's OCaml system, and they use it in their production systems (lots of high-volume trading).
Hmm...Jane Street?
Re: Pyret: A new programming language from the creators of Racket
#244Earlier quoted context omitted.
You seem to be under the impression I haven't programmed in Lispy languages. And our data are from students using DrRacket, which very much has paredit support. These are just inconvenient truths.
DrRacket is a very big language. How does it compare with using a much smaller language such as the Scheme used in SICP?
DrRacket is an IDE that supports many languages. The curricula that Shriram has used at Brown, and that others have used in many other places uses a sequence of smaller languages designed for teaching.
Re: Pyret: A new programming language from the creators of Racket
#245Earlier quoted context omitted.
Except it abandons most of the benefits of lisp.
If s-expressions constitute "most" of the benefits of Lisp, that's a pretty sad statement for Lisp. I don't see any other benefits that it gives up.
Well, the word "macro" doesn't appear on the Pyret home page ... :)
Re: Pyret: A new programming language from the creators of Racket
#246Earlier quoted context omitted.
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 (a…
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 be saying that it isn't worth the trouble because the trouble is considerable. I'd like to hear more about why. (A friend is working on a language where this is an issue.)
p.s. This thread is just awesome. Thank you for engaging so extensively here.
Re: Pyret: A new programming language from the creators of Racket
#247Earlier quoted context omitted.
I would like it if the `where` tests supported DataTables for a slightly more declarative style. Here's an example from Scala/Specs2: https://github.com/snowplow/snowplow/blob/master/3-enrich/ha...
The fact that they don't now doesn't mean they can't in future! One of the advantages of having a separate block for tests is we can do things in that block that won't necessarily pervade the whole language where it might not make sense (which we already do: eg, the keywords "is" and "satisfies"). We've all done some sort of "here's a list of tuples, now map the prefix of this as arguments and the suffix as the expec…
If you can up with a cleaner syntax for test data tables that would be awesome, thanks Shriram.
Re: Pyret: A new programming language from the creators of Racket
#248Earlier quoted context omitted.
> Code folding in a IDE goes a long way to make this bearable. Code folding in IDEs is an indication that we are doing it wrong -- that is, we human beings are programming computers "wrong." I'm not saying that code folding is a symptom. I'm saying that code folding shows how primitive our means of managing code is. It's as if the mesopotamians somehow invented computers, and because of tradition, all code has to be…
Code Bubbles were invented one floor above me (by another team in computer science at Brown University). So, we're not at all unaware of it. And yes, it's great stuff. But we also had to make a conscious decision about IDEs, and we decided to be IDE agnostic -- IDEs should enhance the language but not be the only means of working with it, because programmers are really attached to their editors, and a language predic…
Code Bubbles were invented one floor above me (by another team in computer science at Brown University).
I wrote a significant fraction of a Smalltalk class browser.
IDEs should enhance the language but not be the only means of working with it, because programmers are really attached to their editors, and a language predicated on tearing people away from their editors will struggle.
So, basically you made the pragmatic decision. What you say is true, but I suspect this tendency is ultimately holding us back.
Re: Pyret: A new programming language from the creators of Racket
#249Earlier quoted context omitted.
Sorry, lost track of what you were responding to. Re. your other question, yes, this is a wide-open problem, and we're trying to not get bogged down in research issues like this. We actually have one answer about what to do, presented in a paper we wrote some time ago ( http://cs.brown.edu/~sk/Publications/Papers/Published/gmfk-r... ), but we don't really want to do that. But because we're working on a (curious) type…
Thanks, in a way the non-answer is more useful than a real answer for me :)
I'll read between the lines and just say, "Send us a link to your paper when it's done" (-:.
In fact, we'd really love it if gradual typing folks would tell us what set of primitives they miss in a language. They aren't constrained to what Racket or Python or whatever; there may be a primitive that makes sense that Pyret can add to enable space-efficient, semantically-meaningful contracting or gradual typing in the presence of such operations.
Re: Pyret: A new programming language from the creators of Racket
#250Earlier quoted context omitted.
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 (a…
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 them, I can't refactor G(F(...)) into G(id(F(...))), which is pretty much the definition of an identity function. You should see the true identity function in R5+RS Scheme....
3. The way to make simple functions like that continue to work is to make the return values not be multiple values but a single one (i.e., some kind of tuple). At which point...
4. Pyret's objects are very lightweight. They don't carry baggage à la those in JavaScript, etc.
5. If you have multiple values, every single library function has to be rewritten to work with them. What should map do? filter? fold? And the hundred other library functions? It's also really hard to remember this when writing every line of library code (see #2).
6. We'd need a new binding construct in the language to bind the multiple return values. That's yet more syntax design, but also, it's yet more opportunity for typos to turn into indecipherable error messages ("Expected two values, got one" is a horrible thing to read for someone who doesn't even know a function can return two values!).
So, I claim this is simply not worth the frequency with which you actually need precisely this, as opposed to just returning some sort of tuple or object. Also, once I've bound the return value (say to r), saying r.x and r.y instead of just x and y is really not a big deal.