SIP-6 Explicit Behavior Induction

99 views
Skip to first unread message

Som Snytt

unread,
Apr 1, 2012, 4:20:39 PM4/1/12
to scala...@googlegroups.com

SIP-6 Explicit Behavior Induction

M. O'Dersky, S. Snytt

1 April 2012

Introduction

This is a proposal to incorporate the latest research techniques in behavior induction into the Scala language.

Since this research is strictly cutting-edge, these results are presented in a SIP document rather than getting merged in an extempore commit with a follow-on update to the spec.

This SIP is an extension to SID-6, which was never fully open to input by the community, and builds upon SIP-18 as a prerequisite.  It is motivated by recent research into mass motivators in crisis scenarios.  Since most software projects are in crisis mode most of the time, this research is directly applicable to Scala adoption in the enterprise, an on-going issue which has been discussed on-goingly on the mailing lists.

Motivation

The Scala compiler’s error messages turn out to be very nearly useless.  They are too cryptic for ordinary programmers and too verbose for Scalarati, who need only a source location to see the obvious error (or compiler bug, respectively).  Due to SIP-19, library authors can already omit useful error messages entirely.  This has the pleasant side-effect of excluding non-expert users as library clients; not that anyone programs for side-effects.

Scala clearly needs a mechanism to present appropriate messages to total noobs.  Since everyone was a Scala noob once, and will be again when 3.0 is released, we introduce new nomenclature, viz., nuli, or alternatively newlie,  from the Chinese term, to designate slave programmers pressed into service without any prior training, experience or interest in the Scala language and possibly in programming at large.

Although recent improvements such as SIP-18 seek to address this problem in the aggregate, there is not yet any mechanism to compel a nuli user to take the correct course of action when about to do something really stupid, or, by a sin of omission, to fail to do something that is absolutely required if we're not all going to die or have to look for new work.

The U. S. National Weather Service is kicking off an experiment next week with a new kind of tornado warning that's aimed to scare people into seeking shelter, for instance.

Among the messages in the new warnings: "COMPLETE DESTRUCTION OF ENTIRE NEIGHBORHOODS IS LIKELY" and "MASS DEVASTATION IS HIGHLY LIKELY MAKING THE AREA UNRECOGNIZABLE TO SURVIVORS."

These are the sorts of messages scalac must emit to make sure nuli users are following the Scala Way.  Of course, scala.Way is defined in Predef but may be overridden locally by the usual implicit mechanisms.

The messages themselves can also be localized.  As an example in European English, use of "var" might cause the compiler error: "COMPLETE DESTRUKTION OF ENTIRE ONTOLOGIES IS LIKELY".

Library authors will also be able to customize these messages, using operator symbols from the library itself: "Zipper+ asymmetric lens to move through tree structures -> profit."

With a simple import, these verbose messages can be simplified to: "Don't do that,"  "WTF," or more succinctly, "No."

This mechanism can be extended to other tools in the Scala ecosystem, for example, when attempting to compile a non-trivial project without using SBT.

Specification

The Scala expertise rankings known as Odersky Levels will be encoded as scala.language.Level.An and Ln, where 0 <= n <= 3.  It is expected that the maximum Odersky Level will track approximately k/3 for Scala versions 2.k.  It is also proposed to introduce language.Level.Z1 through Z9 for users of Scalaz pronounced zed.  Note that for notational convenience, Z is not the classic Morris Number, but its inverse, since the Morris scale is normalized at 1 Tony. 

Note that we have introduced language.Level.A0 to the Odersky scale to indicate a total nuli.  (See definition above.)  For convenience, Level.L0 is defined as "A0 with pretensions."  The equivalent Morris Number is Level.NaN, read, "Not a Nous" (νοῦς).

Sometimes you see an error message from scalac or sbt that makes you go, "Boy, am I dumb."  A moment later, we realize we're too dumb even to understand the error message.  But why display an error message I can't understand?  Moreover, certain errors indicate that I'm just such a programmer who won't understand it, so that we know at compile-time that a whole class of errors is not worth reporting, because they will be essentially meaningless to the user.  Therefore, the compiler will not display those errors unless an explicit import language.Level.L3 is available.  This mechanism will also inhibit copy-pasting these errors to the scala-language forum. 

It will be allowed to import language.Level._, but this will cause compilation to halt immediately and scalac will exit silently with value 0.


Josh Suereth

unread,
Apr 1, 2012, 4:45:17 PM4/1/12
to scala...@googlegroups.com

Ah.... April 1st humor....

Chris Marshall

unread,
Apr 1, 2012, 5:27:02 PM4/1/12
to scala...@googlegroups.com, scala...@googlegroups.com
Well; it made me laugh anyway

Chris

Trond Olsen

unread,
Apr 1, 2012, 8:43:35 PM4/1/12
to scala...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages