ERights Home download / 0-8-30 
No Previous Sibling On to: SWT Support

Highlights of 0.8.30d


Non-Upwards Compatible Changes

New features

Bugs Closed

Non-Upwards Compatible Changes

"//" replaces "_/" as the floorDivide operator syntax

This now corresponds more closely with Python's usage. See the thread containing Complex, rational, and other sorts of numbers in E.

? def x := 3
# value: 3

? def x_ := 4
# value: 4

? pragma.enable("dot-props")
? interp::expand := true
# value: true

? x_/1
# expansion: x_.approxDivide(1)

# value: 4.0

? x _/ 1
# syntax error: For division,
#               use '//' to truncate to the least integer,
#               'truncDivide' to truncate to the int nearest to zero (least magnitude),
#               and '/' for a float64 approximation.
#   x _/ 1
#     ^

? x // 1
# expansion: x.floorDivide(1)

# value: 3

? -5 // 3
# expansion: 5.negate().floorDivide(3)

# value: -2

? (-5).truncDivide(3)
# expansion: 5.negate().truncDivide(3)

# value: -1 

Removal of previously deprecated or unofficial features

__yourself

The previously deprecated Miranda method "__yourself" is gone. Thanks to Kevin Reid for suggesting that it was now time to remove it.

e.enable.synthetic-slot and e.enable.access-slot

These syntax switches were never really useful, and have now been retired. Instead, the experimental foo::&bar syntax is now available, as explained below.

New Reserved Keyword: "delicate"

This keyword has been added to the list of reserved keywords, but doesn't currently do anything. I reserved it after a conversation with Jonathan Shapiro, which led me to think it might be good to provide syntactic support for a "delicate section". A delicate section would be a block of code that, once entered, the programmer assumes will be able to complete successfully, i.e., that it will not exit by throwing a problem. Let's say we can declare a delicate section by syntax like "delicate { expr }".

The semantics would be that, if expr does exit by throwing a problem, the current vat incarnation aborts, as this is not a situation in which we expect to be able to recover consistency. If this vat is persistent, then aborting the current incarnation will cause it to roll back to its most recent checkpoint, which is its only reliable hope.

(Alternatively, "delicate" could be the name of a function, and we could write "delicate(thunk{expr})". This is probably superior on all dimensions. To enable this to be written in the language, E's try-catch block would need to be changed to catch Errors as well as Exceptions, but still not Ejectors. To support this and other uses, we have reserved __abortIncarnation() in the safe scope, but we must eventually implement it.)

New features

What should 'foo.bar' mean -- property access or curried verb access? (Link please to previous e-lang discussion?) Thanks to Tyler Close's web calculus for suggesting the desireability of currying on the verb, as a cheap way of making a facet. Thanks to Kevin Reid for suggesting this way of resolving the conflict: 'foo.bar' should be curried verb access (as well as 'foo <- bar'), and we introduce the new experimental syntax 'foo::bar' for property access.

Both of the following are experimental: they are not an official part of the language, and are off by default. To use these, you must turn on the appropriate syntactic switch.

Experimental: Property Slot Access / Non-identifier variables

  • New Syntax: foo::propName

    The new experimental syntax for property access is 'foo::propName' rather than the old 'foo.propName'. Rather than expanding directly to 'foo.getPropName()' as it used to, in order to accomodate other property naming conventions (as in Corba & .NET), it now expands to 'foo.__getPropertySlot("propName").getValue()'. Likewise, when used as an lValue, 'foo::propName := newValue' expands approximately to 'foo.__getPropertySlot("propName").setValue(newValue)', except that the expansion also arranges that the value of the assignment expression is newValue. Finally, 'foo::&propName' expands directly to 'foo.__getPropertySlot("propName")'

  • Relevant Syntactic Switch: e.enable.dot-props

    This syntax can only be used when the "e.enable.dot-props" switch is turned on, such as by a 'pragma.enable("dot-props")'. Since we are now using a double colon for this rather than a dot, this syntactic switch name is now stupid. But the concept is the same, so we're keeping the old name.

  • New Miranda Method: __getPropertySlot/1

    When the argument is an identifier, the Miranda behavior for 'foo.__getPropertySlot("propName")' synthesizes a Slot whose getValue() behavior does a 'foo.getPropName()', and whose setValue(newValue) behavior does a 'foo.setPropName(newValue)'.

Experimental: Curried Verb Access

  • New Syntax: foo.bar and foo <- bar

    The old experimental syntax 'foo.bar' is no longer interpreted as an attempted property access, but rather as a currying of the message selector (i.e., the verb). 'foo.bar' expands into '__maeVerbFacet.curryCall(foo, "bar")'. Likewise, 'foo <- bar' expands into '__makeVerbFacet.currySend(foo, "bar")'.

  • Relevant Syntactic Switch: e.enable.verb-curry

    This syntax can only be used when the "e.enable.verb-curry" switch is turned on, such as by a 'pragma.enable("verb-curry")'.

  • New universally accessible object: __makeVerbFacet with methods curryCall/2 and currySend/2

    These methods cause '(foo.bar)(args...)' to have the same effect as 'foo.bar(args...)', and '(foo <- bar)(args...)' to have the same effect as 'foo <- bar(args...)'. In addition, the curried object created by these methods respond to __respondsTo/2 and __getAllegedType/0 according to the response of the original foo object to bar messages, as seen in the examples below.

Example Session

? pragma.enable("verb-curry")
# expansion: null

? def exiter := interp.exitAtTop
# expansion: def exiter := __makeVerbFacet.curryCall(interp, "exitAtTop")

# value: <calling "exitAtTop" facet>

? help(exiter)
# expansion: help.run(exiter)

# value: an org.erights.e.elang.evm.EImplByProxy
#        /**
#         * A facet-function on some underlying object for sending only messages
#         * with a given verb (message selector) to that underlying object.
#         * <p>
#         * For example, '<tt>foo.bar</tt>' results in a function such that
#         * '<tt>(foo.bar)(args...)</tt>' invokes '<tt>foo.bar(args...)</tt>'.
#         */
#        interface "org.erights.e.elang.interp.__makeVerbFacet$makeVerbFacet__C$verbFacet__C" {
#
#            /**
#             * Exit reporting successful completion
#             */
#            to run() :any
#
#            /**
#             * Exit reporting optProblem as the reason for termination.
#             * <p>
#             * If optProblem is null, this indicates successful completion.
#             * If optProblem isn't null, it's the alleged reason for unsuccessful
#             * termination.
#             */
#            to run(_ :any) :any
#        }
#

? def &expander := interp::&expand
# expansion: def &expander := interp.__getPropertySlot("expand")

# value: ::&expand

? def setExpander := interp.setExpand
# expansion: def setExpander := __makeVerbFacet.curryCall(interp, "setExpand")

# value: <calling "setExpand" facet>

? expander
# expansion: expander

# value: true

? setExpander(false)
# expansion: setExpander.run(false)

? expander
# value: false

? expander := true
# value: true

? expander
# expansion: expander

# value: true

Experimental eventual property access syntax

Thanks to David Hopwood for suggesting this natural extension of the above property access syntax, for use with eventual references.

? def expVow := interp <- ::expand
# expansion: def expVow := E.send(E.send(interp,\
#                                        "__getPropertySlot",\
#                                        __makeList.run("expand")),\
#                                 "getValue",
#                                 __makeList.run())

# value: <Promise>

? interp.waitAtTop(expVow)
# expansion: interp.waitAtTop(expVow)

? expVow
# expansion: expVow

# value: true

? def expSlotVow := interp <- ::&expand
# expansion: def expSlotVow := E.send(interp,\
#                                     "__getPropertySlot",\
#                                     __makeList.run("expand"))

# value: <Promise>

? interp.waitAtTop(expSlotVow)
# expansion: interp.waitAtTop(expSlotVow)

? expSlotVow
# expansion: expSlotVow

# value: ::&expand

RSAPublicKey and RSAPrivateKey now serialize with Data-E

0.8.30d still uses DSAPublicKey and DSAPrivateKey for vat-identities, and these continue to serialize with Data-E.

This release now also serializes RSA keys, which we expect to use in the upcoming switch to TLS and the Redirectory.

Bugs Closed

    Thanks to...
Nondeterminism leak in BaseAuditor#coerce/2 Kevin Reid
MessageDesc#synopsize expanded whitespace  
FileSugar#copyTo doesn't create needed directories Anthony Hannan
Ref.whenResolved doesn't accept non-near 2nd argument Kevin Reid
Expansion of expr with undefined variable isn't printed Kevin Reid
JComboBox prints in the wrong thread Kevin Reid
 
Unless stated otherwise, all text on this page which is either unattributed or by Mark S. Miller is hereby placed in the public domain.
ERights Home download / 0-8-30 
No Previous Sibling On to: SWT Support
Download    FAQ    API    Mail Archive    Donate

report bug (including invalid html)

Golden Key Campaign Blue Ribbon Campaign