Table of Contents

AmbientTalk/2 ChangeLog

Deprecated. See the one on google code instead

build140508 (v 2.9)

build130208 (v 2.8)

build170907 (v 2.7)

[1, 2, 3].map: .+(1).from(self) ⇒ [2,3,4]

build270707 (v 2.6)

a) o.m == o.m() if m is bound to a method (if it is bound to a field, the field's value is still returned) b) m == m() if m is bound to a lexically visible method c) first-class methods are still supported, but require explicit syntax: o.&m will grab the method as a first-class closure. If m is bound to a field instead, o.&m will return an “accessor” closure which is a nullary closure yielding the field's value upon application. Method selection also works lexically: &m yields an accessor or closure for a lexically visible field or method. d) assignment is now treated as message passing, with x := 5 being equal to lexically invoking a method named “x:=” and o.x := 5 being equal to sending o the message “x:=”.

The UAP change is unfortunately not entirely backward-compatible with existing AmbientTalk code. When you upgrade to this release, you'll have to check the following: a) where you used to write 'o.m' to select a method as a first-class closure value, you should now write 'o.&m' because 'o.m' is now treated as invoking the method (i.e. o.m()) b) where you used to write 'm' to select a lexically visible method to grab a method as a first-class closure value, you should now write '&m' because 'm' is interpreted as applying the method (i.e. m())

build190607 (v 2.5)

While this change is not backwards-compatible with current AT code (you really need to find/replace all occurences of these language constructs), we feel it is best to make this name change as soon as possible, rather than carrying an ill-chosen name for the rest of AT/2's life.

build080507

Bugfixes:

build060407

System library additions:

Implementation changes:

Bugfixes:

build230307

The futures language module now also exports two stripes, 'FutureMessage' and 'OneWayMessage'. When the 'FutureMessage' is attached to a message send, the message will always return a future (if the futures language module is activated). If 'OneWayMessage' is attached to a message send, the message will use the default behaviour (i.e. normally return 'nil') even if the futures are enabled. Hence, you have two options to work with futures from now on: you can evaluate 'enableFutures(true)' to make ← return futures by default, and use o←m()@OneWayMessage to create pure asynchronous messages without futures, or you can evaluate 'enableFutures(false) to make ← behave normally (i.e. return nil) and then use o←m()@FutureMessage to explicitly require the creation of futures.

build150307

actor.install: now takes an arbitrary 'protocol' object and installs that object as the mirror of the actor. Also, its return value is no longer an object you can use to 'unmix' the protocol. Rather, it now returns the old installed protocol. If you still want to mimick the old behaviour, you can do so with code like: 

def mixin(protocolCode) {
  def oldActor := actor.install: (extend: actor with: protocolCode);
  object: {
    def uninstall() {
      // restore the previously active protocol
      actor.install: oldActor
    }
  }
}
def trait := object: {
  def foo() { self.bar() + 3 };
  def bar() { 5 };
  def baz := 3;
};

def obj := object: {
  import trait alias bar := tralala exclude baz;
  def bar() { 1 };
}

obj.bar() => 1
obj.foo() => 4
obj.baz => error
obj.tralala() => 5

Example: 

import /.at.lang.futures;
enableFutures(); // changes the MOP of the current actor
def id(x) { x }
when: self<-id(42) becomes: { |val| system.println(val == 42) }

It might be that we later decide to invoke 'enableFutures()' automatically when you load the futures module.

path1:path2:path3:… to name1=path1:name2=path2:name3=path3:… The names given in the path will be the names of slots defined in the lobby at startup time. For example, if you specify: 

iat -o foo=/Users/me/test:bar=/usr/local/lib

Then in AmbientTalk: lobby.foo is bound to the namespace “/Users/me/test” and lobby.bar is bound to the namespace “/usr/local/lib”

$AT_OBJECTPATH:at=$AT_HOME/at In other words: it uses the value of $AT_OBJECTPATH if that variable exists (cfr. Java's $CLASSPATH) and always includes the 'native' library which will be known under the name at. You will see that in the new build, the native library is shipped in the at subdirectory. It is now allowed to shadow names in the object path (a warning is printed on the console to make you aware of the shadowing). For example, if your $AT_OBJECTPATH equals foo=/usr/lib/ambienttalk and you start iat using: 

iat -o foo=/test:$AT_OBJECTPATH

then lobby.foo will be bound to /test 

-DAT_HOME="${project_loc:AT2 Library}/edu/vub"

This passes to the JVM the value of the AT_HOME property. It is set to the location of the edu/vub subdirectory of the AT2 Library project, which contains the native AT library. Note that if you named that project differently, you need to adapt the string “AT2 Library” to match your project name.