Lambda the Ultimate

We have a new apprentice programmer here at work, and I was trying to explain to her the difference between complete and lazy boolean evaluation, and why she should be always be mindful of side effects when it's turned on or off. While she grasped the concept well enough, she confounded me in asking why the distinction exists in the first place (seeing as it creates side effects).

This got me thinking whether "semi-complete" boolean evaluation would be an asset to an imperative PL.

For example:


// Scenario A:
if (boolVar1) and (boolVar2) then
.
.
.
endif;



// Scenario B:
if (boolVar) and (someObjectInstance.someBoolMethod) then
.
.
.
endif;



//Scenario C:
if (someObjectInstance1.someBoolMethod) and (someObjectInstance2.someBoolMethod) then
.
.
.
endif;


In scenario A, completely lazy evaluation is the preferred way, because the expressions being evaluated are boolean variables, pure and simple, and the compiler should automatically enable lazy evaluation for that conditional.

In scenario B, someObjectInstance.someBoolMethod might do some internal processing that we want regardless, yet the ordering of the expressions determines that that might not happen if BoolVar is false and the expression is evaluated "lazily". This in some ways spoils the pure nature of boolean logic because expression order becomes important in determining the result, and switching lazy eval on/off becomes an issue.

Similarly, in scenario C, the same issues apply.

I realise that these issues can be avoided by reordering or splitting the conditional statements into multiple if/then's, but what about if the language, as a rule, ALWAYS evaluated expressions, if they were methods or function calls, regardless of where they occured in the conditional. For scenario B, for example, that would mean that even if boolVar was false, the someObjectInstance.someBoolMethod still gets called, except that the conditional statements below get skipped .

The overall effect would be that the language always presents complete evaluation to the programmer (who then does not have to factor in expression order), but can benefit from lazy evaluation if the compiler deems it appropriate.

It could perhaps also be possible to have a language construct to force the lazy evaluation, for example:


ifl (BoolVar) and (someObjectInstance.someBoolMethod) then...


or


if (BoolVar) and ?(someObjectInstance.someBoolMethod) then...


or suchlike, with the compiler giving appropriate warnings where neccessary.

I understand that allowing expression order to be an issue, is A Bad Thing regardless, to be avoided by careful code habits. I am also not neccessarily advocating the "semi-lazy" method, as I recognise how it introduces a new way of creating undesirable side effects (namely what happens inside the called methods), but I am nevertheless interested in hearing your comments on the topic.

Regards,
Riaan

I've recently been looking at high-level ontologies, such as CYC and SUMO for a project I'm working on. Clearly, there is a connection between techniques used for organising class hierarchies and those used for organising ontologies (class hierarchies are ontologies, at least superficially). Going further, there seems to be an overlap between languages' standard class libraries and these high-level "common sense" ontologies. Each describes quite general concepts like "objects", "processes", "sets" and "classes", and then provide more specific concepts for particular domains. With RDF and OWL becoming popular (or not?), I wonder if there will be a merging between these two similar areas. Are there any languages that come with a standard ontology? Are there languages whose tools for modelling class hierarchies more closely resemble those of ontology authoring tools? For instance, supporting more than just "subtype" and "instance" relations (i.e., more like first-order logic or a description logic). Haskell's type-classes come to mind. Is there any restriction on the kinds of relations between types that can be expressed by type-classes? Are there techniques that can be applied to type/class-level organisation from ontology modelling?

The Scala language fuses object-oriented and functional programming while staying completely interoperable with Java. It is compiled to JVM class files, subclassing is allowed both ways between Java and Scala classes, and no glue code needs to be written by users.

Scala also adds several important and convenient constructs, such as:

- mixin composition with traits,
- first-class functions,
- case classes and pattern matching,
- XML expressions and patterns,
- virtual types,
- for-comprehensions,
...

The second major version of Scala is now publicly available. This version adds some new constructs to the language and simplifies some idioms (http://scala.epfl.ch/docu/scala2.html).

There are also the following new tools:

- a new `scalac' compiler, which is completely written in Scala

- a new `scalaint' interpreter shell, which is integrated with the compiler and which drops most restrictions of the previous version.

- a new Eclipse plugin. See http://scala.epfl.ch/docu/eclipse/index.html

- a new tool `sbaz' to manage and distribute Scala packages. See http://scala.epfl.ch/downloads/sbaz.html

This implementation runs on the Java VM, JDK 1.4 or 1.5. An automatic installer is available for Windows, MacOS X, Linux, Solaris, and most other operating systems.

For further information and downloads, please visit:

http://scala.epfl.ch