Request for Comments: Deprecate (&) in CodeWorld

[Chris Smith]

Hi everyone!

Over the last few months, the possibility has come up that CodeWorld's (&) operator was a mistake, at least in the educational dialect.  This school year, a group at LSU has been trying a trial with 1000 students learning from CodeWorld without it, and it's been successful.  This would, of course, be a HUGE breaking change, so I want to share thoughts, and get feedback on the approach.

The Problem

In short:

1. Students struggle with the notion of new binary operators.  It's a big impediment to understanding, and it's clear that despite our best efforts, students learn (&) as a special-case of syntax, not as just another binary operator.

2. The specific choice of operator is an even bigger hurdle.  It looks like a generic piece of English grammar, and many students never quite understand that it represents a specific function on pictures, rather than the generic notion of "and also..."

3. The alternative, the pictures function, is too generically named.

I am aware that removing the (&) operator means teaching list syntax earlier.  LSU's experience is that this concern is far outweighed by the advantages of the new approach.  By confronting types, including the list type, earlier and meeting the problem head-on, students and teachers also understand error messages better, and have a specific function name to categorize their understanding of this key function.

The Proposal

The proposal is to do two things at the same time: rename the existing "pictures" function to "layered", and also deprecate and remove (&).  All code that is currently written with pictures or & (and yes, that means basically everything ever written in CodeWorld!) would need to be migrated to use layered, instead.

The Process

This would be an extremely slow change.  It would proceed in these steps:

1. Add the new layered function.  Wait a couple months to play around with it and surface any concerns.

2. Begin modifying the Guide and official sample code to migrate to use the layered function.  Work with anyone hosting CodeWorld activities elsewhere to update, as well.

3. Once this is complete, wait at least one year, during which both approaches work equally well.

4. Add deprecation warnings to pictures and (&).  This will cause warnings in code pointing to the replacement, as well as special syntax highlighting to raise awareness that they are deprecated.

5. Wait two to three more years for current practice to change and the long tail of users to have the time to update.

6. Finally, remove pictures and (&).

Haskell Mode, Too?

Probably.  I think I'm somewhat persuaded by not wanting codeworld-api and codeworld-base to diverge.  Haskell mode also already has another binary operator (<>) that works, since `Picture` is a monoid.

I'm interested in thoughts from users of Haskell mode about the right outcome here, though.

[Janis Voigtländer]

User of Haskell mode here. Context: teaching a "declarative programming" course for university undergraduates.

Some thoughts I have:

Is "layered" the best possible name? The function is often used in situations where there is no geometric overlapping between the pictures being combined. Of course, one can still think of layers then. And yet, I would probably want a name more in the spirit of "combined", then. Though I do see the appeal of "layered" in other situations.

Replacing "&" might be a small win. I sometimes see students confuse it with "&&".

Two possible disadvantages of using "<>" as the replacement for "&":

- It needs two letters. Not so much an issue of the number of keystrokes. But the concept "custom two-letter operator" appearing very early in the course might confuse students a tad, coming from languages that have predefined operators (like "&&", "!=", ...) at most.

- It has a quite generic type. So error messages for wrong use of "<>" will tend to be confusing for beginning Haskell students (suddenly being told something about Semigroup), whereas with the current operator of concrete type "Picture -> Picture -> Picture" the error messages are useful (for example in situations where students do confuse "&" and "&&").

I'm wondering whether the Haskell mode should maintain an operator (be it "&" or differently named) of concrete type "Picture -> Picture -> Picture" even when the other dialect doesn't have it.

--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/CAPq5PvKwXwhmuMXYsAaUcRqmju2B6uK4kjVpTpTskMQvxL5zMA%40mail.gmail.com.

[Janis Voigtländer]

Another small disadvantage of using a replacement operator that is not specifically Picture-typed: It would prevent giving certain automatic hints to students via HLint.

The CodeWorld section of HLint's hint database (https://github.com/ndmitchell/hlint/blob/master/data/hlint.yaml) currently contains these:

imports:

- package base - package codeworld-api rules: - warn: {lhs: "pictures [ p ]", rhs: p, name: Evaluate} - warn: {lhs: "pictures [ p, q ]", rhs: p & q, name: Evaluate} - hint: {lhs: foldl1 (&), rhs: pictures} - hint: {lhs: foldl (&) blank, rhs: pictures} - hint: {lhs: foldl' (&) blank, rhs: pictures} - hint: {lhs: foldr' (&) blank, rhs: pictures} - hint: {lhs: foldr (&) blank, rhs: pictures} - hint: {lhs: foldr1 (&), rhs: pictures} - hint: {lhs: scaled x x, rhs: dilated x} - hint: {lhs: scaledPoint x x, rhs: dilatedPoint x} - warn: {lhs: "brighter (- a)", rhs: "duller a"} - warn: {lhs: "lighter (- a)", rhs: "darker a"} - warn: {lhs: "duller (- a)", rhs: "brighter a"} - warn: {lhs: "darker (- a)", rhs: "lighter a"}

The hints about foldl1 and foldr1, that contain & but not also blank, could not be written in  a world with <> as the relevant operator, since they are not true for all instances of <> and since the left-hand sides of those rules contain nothing that would ensure the actual type in the expression is Picture.

[Joachim Breitner]

Hi,

Am Donnerstag, den 22.10.2020, 11:44 -0400 schrieb Chris Smith:
> Haskell Mode, Too?
>
> Probably. I think I'm somewhat persuaded by not wanting codeworld-
> api and codeworld-base to diverge. Haskell mode also already has
> another binary operator (<>) that works, since `Picture` is a monoid.
>
> I'm interested in thoughts from users of Haskell mode about the right
> outcome here, though.

I think it would break the “Haskell via Sokoban” course approach.
There, a design goal is to _not_ use Haskell’s [] list type, but
rather, later in the course, let the student define their own
`data
List`.

I might be able to use `(<>)` here, and hand-wave away the fact that
it’s type signature is more general. Error messages might be confusing.

Or I might tell users to put some unexplained code in their file that
introduces a suitable operator. Probably also ok.

It’d also seem odd if there is layered, which is obviously a fold,
without the binary operation that this fold is based on, and that has
`blank` as the neutral element? So maybe, in either case, introduce a
binary `onTopOf` (even if not commonly used)?

Cheers,
Joachim




--
Joachim Breitner
ma...@joachim-breitner.de
http://www.joachim-breitner.de/

[Jan Peter Axelsson]

Hi

I note that my recent post relate to your discussion around "&" but with a slightly different angle.

There are aspects in your argumentation I am too much newbie to follow and value.

Joachims suggested replacement of "&" with "onTopOf" is perhaps a way, but perhaps a lot to write all the time, but rather clear. Problem is you may think of a "pile" of pictures, which it is, but not that much overlapping after all. 

Introducing operation on a list has perhaps drawback that I do not get, bu my suggestion was

    beachBall = composedOf [stripe, ball, sand, sky]

(and function composedOf = pictures)

see my post.

I also understand the difficulty to upgrade basics like this and bring runtime error to a lot of code.

But parallell solutions can live side by side for some time, as usual, I guess.

Cheers 

Jan Peter