This is substantially interesting to me personally, persuant a paste below, as a spectator of PLD. Pretty keen to read the, Hey, but, wait, Alfred Matthews. Better Collaboration One of the most difficult things about collaborative development is handling merge conflicts. The vast majority of merge conflicts are results of non-functional changes: Renames, reformatting, textual movement of code lines between files, etc. In Lamdu, "names", the "position" of the code and other non-functional aspects of code are separate from the code itself, and avoid conflicts. Rename conflicts To get a conflict due to "rename" operations, two developers must rename the same variable to two different names. Even then, the code is still executable, but its on-screen rendering will display a localized conflict. Formatting conflicts Formatting is automatic, so there is no way to generate a conflict. Code movement conflicts The "position" of code is meta-data attached to the code, helping to find that code and position its rendering. Since code is not structured into text files, code "position" conflicts are similarly less harmful, less likely and localized. Change tracking Instead of heuristically guessing what changed in the code, as traditional version control systems do, Lamdu uses an integrated revision control system and records the changes by the programmer as revisions. This acts as a record of the developer's intent, allowing the RCS to distinguish, for example, between function deletion and writing of a similar function, and the modification of that same function. The recording of intent helps prevent and resolve conflicts. Regression Debugging Integrated revision control and live test cases will allow "Regression Debugging". When a change causes a regression, the root of the problem can be found quickly, by finding the deepest function application whose result value diverged from the correct version of the code. Automatic Formatting and Sugaring Lamdu attempts to take away as much inconsequential freedom from the developer, to free his mind and his key strokes to deal with the parts that matter in the code. Thus, Lamdu does not provide means to edit formatting on a case-by-case basis. Generalized changes to layout rules can be provided, instead. Additionally, to avoid further stylistic dilemmas, Lamdu uses automatic sugaring of code, as the dual of typical "de-sugaring" done by textual languages. The code is edited and displayed in its sugared form. The edits to this form are translated to lower-level, simpler edits of the stored language, which is de-sugared. Lamdu uses "co-macros" that capture patterns in the lower-level code and automatically sugar it to canonical form. This frees the programmer from worrying about whether to use sugar for each particular case. On Thu, Apr 26, 2018, 5:16 AM Alan & Kim Zimmerman wrote:

See lambdu.org

On 26 April 2018 at 10:47, Alex McLean wrote:

...

Hi all,

I'm wondering if anyone has made a 'block editor' for Haskell, i.e. a syntax-aware text editor where you make a program by snapping together type-compatible words, usually with a mouse. Something similar to Scratch for example: https://scratch.mit.edu/

Any leads appreciated!

Best wishes

alex

_______________________________________________

...

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.