Non-Upwards Compatible Changes Non-Upwards Compatible Changes"//" replaces "_/" as the floorDivide operator syntaxThis 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__yourselfThe 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-slotThese 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 featuresWhat 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
Experimental: Curried Verb Access
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 syntaxThanks 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-E0.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
|
|||||||||||||||||||||||||||||||
Unless stated otherwise, all text on this page which is either unattributed or by Mark S. Miller is hereby placed in the public domain.
|