IEEE Scheme expiring soon

Scheme has an IEEE standard, IEEE 1178-1990, which describes a version of the language slightly later than R4RS (#f and the empty list are definitely different) but not yet R5RS (no syntax-rules, dynamic-wind, or multiple values). That standard was reaffirmed unchanged in 2008, and will come up again for renewal in 2018. What's the Right Thing?

I see three reasonable courses of action:

1) Do the work to make R7RS-small the new edition of IEEE Scheme.

2) Do the (lesser amount of) work to reaffirm IEEE Scheme unchanged for the second time.

3) Do nothing and allow the IEEE standard to expire.

Does anyone still care about having an official, citable standard for Scheme?

(When I brought the question up on #scheme, someone asked what R7RS-small implementations exist. Currently there are Chibi, Chicken (partial), Foment, Gauche, Guile (partial), Husk, Kawa, Larceny, Mosh (partial), Picrin, Sagittarius.)

SFI Talk: Four the hard way: Computer design and living software

Just a funny talk I found on the Interwebs by Dave Ackley.

SFI Talk: Four the hard way: Computer design and living software

I don't think his ideas are particularly new but it's good to see them stated directly in a talk once.

The end result is something seemingly tangent to what is possible at the moment, scalable hardware with a programming language on top.

Best opening sentence ever, in a paper on S-Exprs for IDEs.

The paper Haskell-Like S-Expression-Based Language Designed for an IDE appeals to me at the moment because I actually like the regularity of s-exprs (to side-step the inevitable technopsychobabble corners people paint themselves into otherwise) but still really want static type checking (with some inference, probably).

The intro is great and I won't spoil it, here's what is just after the opening jab.

This report documents the results of designing a modern programming language with its IDE in mind. We introduce a new statically typed functional language with strong metaprogramming capabilities, targeting JavaScript, the most popular runtime of today; and its accompanying browser-based IDE. We demonstrate the advantages resulting from designing both the language and its IDE at the same time and evaluate the resulting environment by employing it to solve a variety of nontrivial programming tasks. Our results demonstrate that programmers can greatly benefit from the combined application of modern approaches to programming tools.

Plus, any paper that mentions Shen and Elm and Flow et. al. can't be all bad.

P.S. I think this video is very nice, too.

(some extra keywords: xixixao, Shem, Golem)

¿How can a dynamically typed language not actively prevent static checking?

With all due serious respect to: TypedRacket, TypedLua, Dialyzer, TypeScript, Flow, et. al., I see most if not all attempts to add some form of static type checking to a dynamic language to be indictments of the whole venture. Sure, they might get close to having something, but the something is so far away from 'the goal' that it is proof of the tilting at windmill nature of it all. From my Day Job Joe Programmer Static Typing Bigot perspective.

Cf. the long and complicated list of Flow issues on GitHub.

I realize that building a language with typing from the ground up is empirically hard to do, or empirically hard to conceive of doing anyway. Thus instead of asking for Magic Pixie Dust Retroactive Static Typing libraries, I think I would like to ask: How can dynamic language creators at least make their dynamic language more rather than less amenable to some possible future static typing analysis?

(Of course the answer is to use some static typing engine to lint the grammar/possible productions/whatever, which is obvious and sad and ironic and undermines any such dream ever being fruitful.)

Or should we just admit that anybody who thinks we can have our dynamic cake and eat it too is barking up the wrong tree?

Feedback requested: A sample implementation of L-systems in Haskell

A while back I published a draft of an article I wrote to explore L-systems, specifically D0L systems, and would very much enjoy any feedback (positive or negative) of what I have written.

A sample implementation of L-systems in Haskell

Primarily, the content which gives me pause is the mathematics revolving morphic words as I have yet to fully grok them in any greater sense than the one that I have used in my implementation.

Please, critique my work and point out any errors.

Kind regards,
Filip Allberg

Is the "Getting started"-guide up-to-date?

The Getting Started thread is very educational, but I am writing to point out that as time progresses more literature comes into being and there might be a more efficient way to digest programming language theory, category theory, programming language design, functional programming etc. I would love to see a curated list that describe a nice progression path from apprentice to journeyman and beyond, that still could be community maintained much like the getting started guide.

There could even be different suggested paths. I for one have programmed a lot of software, and my knowledge mostly pertains to maintainability, and software engineering approaches to distributing knowledge and writing robust systems. I am however very interested in the concepts that this site pertains to, but I have a lot of difficulties approaching it solely from a theoretical stand-point. I need application, and I find that until one's own knowledge moves beyond a particular point does it become possible to dream up one's own applications and sandbox-experiments.

And, I am sure there are other individuals that approach these concepts from a more mathematical standpoint, but I cannot much speak for them as a group as I am not amongst them.

Kind regards,
Filip Allberg

I have been exploring Rust as of late, which has an affine type system (I hear). Is there any good introductory papers to familiarize oneself with the subject on a theoretical basis? I would have an easier time starting from a practical mindset that interleaves the "necessary" theory, edging increasingly toward a purely theoretical view but I realize that may not exist.

Kind regards,
Filip Allberg

LIVE 2016 @ ECOOP (CFP)

LIVE 2016 aims to bring together people who are interested in live programming. Live programming systems abandon the traditional edit-compile-run cycle in favor of fluid user experiences that encourage powerful new ways of “thinking to code” and enable programmers to see and understand their program executions. Programming today requires much mental effort with broken stuttering feedback loops: programmers carefully plan their abstractions, simulating program execution in their heads; the computer is merely a receptacle for the resulting code with a means of executing that code. Live programming aims to create a tighter more fluid feedback loop between the programmer and computer, allowing the computer to augment more of the programming process by, for example, allowing programmers to progressively mine abstractions from concrete examples and providing continuous feedback about how their code will execute. Meanwhile, under the radar of the PL community at large, a nascent community has formed around the related idea of “live coding”—live audiovisual performances which use computers and algorithms as instruments and include live audiences in their programming experiences.

We encourage short research papers, position papers, web essays, tool demonstrations (as videos), and performance proposals in areas such as:

• Recent work in REPLs, language environments , code playgrounds, and interactive notebooks.
• Live visual programming.
• Programming by example.
• Programming tools for creative experiences and interactive audio visual performances.
• Live programming as a learning aid.
• Fluid debugging experiences

Submissions will go through EasyChair. Papers and essays must be written in English and provided as PDF documents. As a recommendation, papers should be around 5 pages and videos should be 5-10 minutes in length; other non-paper submissions should consume no more than 30 minutes of a casual reader’s time. However, papers up to 10 pages and videos up to 20 minutes are also welcome. Video and non-paper submissions can by listed as URLs (e.g. to a web page, file locker, or streaming site) in the submission’s abstract. At the author’s discretion, workshop articles can be published using an institutional ISBN with full support for open access.

Why not C++?

There is a subset of C++ that is supposedly the bee's knees, according to Stroustrup, Sutter, and Dos Reis. Not to start an opinionated flame war, I want to know if you believe their argument holds enough water. I mean this both technically (if you stick to what they say, does it work) and in terms of practicality (are humans able to do that). To whatever extent you disagree, what are viable alternatives?

I mean this both about what they say works (their approach using 'good' C++), and what they say doesn't (cf. gc finalizers).

You can write C++ programs that are statically type safe and have no resource leaks. You can do that without loss of performance and without limiting C++’s expressive power. This model for type- and resource-safe C++ has been implemented using a combination of ISO standard C++ language facilities, static analysis, and a tiny support library (written in ISO standard C++). This supports the general thesis that garbage collection is neither necessary nor sufficient for quality software. This paper describes the techniques used to eliminate dangling pointers and to ensure resource safety. Other aspects – also necessary for safe and effective use of C++ – have conventional solutions so they are mentioned only briefly here.

The techniques and facilities presented are supported by the Core C++ Guidelines [Stroustrup,2015] and enforced by a static analysis tool for those [Sutter,2015].

Onward 2016 call

The Onward call for papers is on, with a submission deadline of April 1st this year. Please consider submitting your edgy PL ideas.

Onward! is looking for grand visions and new paradigms that could make a big difference in how we will one day build software. But Onward! is not looking for research-as-usual papers—conferences like OOPSLA are the place for that. Those conferences require rigorous validation such as theorems or empirical experiments, which are necessary for scientific progress, but which typically preclude discussion of early-stage ideas. Onward! papers must also supply some degree of validation because mere speculation is not a good basis for progress. However, Onward! accepts less rigorous methods of validation such as compelling arguments, exploratory implementations, and substantial examples. The use of worked-out examples to support new ideas is strongly encouraged.

Onward! is reaching out for constructive criticism of current software development technology and practices, and to present ideas that could change the realm of software development. Experienced researchers, graduate students, practitioners, and anyone else dissatisfied with the state of our art is encouraged to share insights about how to reform software development.