Mark Miller | 2 Aug 20:50 2004

Announcing Release Candidate 0.8.30c: Suggestions Implemented

0.8.30b is withdrawn as a release candidate.
Announcing Release Candidate 0.8.30c at

This release implements Kevin's email below, suggesting how the experimental 
features introduced in 0.8.30b should have been implemented. (Thanks, Kevin!)

At 11:26 AM 7/29/2004  Thursday, Kevin Reid wrote:
>On Jul 29, 2004, at 2:01, Mark Miller wrote:
>>        •       New Miranda Methods: __getProperty/1 and __setProperty/2
>Um. This seems an inconveniently wide interface to me. Wouldn't it be better 
>to have only __getPropertySlot/1, so that the objects implementing it only 
>need to lookup property names in one place?

Done, as documented on the revised highlights page at

>> The current behavior for non-identifiers is still experimental, and not yet ready to be explained; but
the intention is to support either '&foo::propName' or 'foo::&propName' as a way of asking for the Slot
object holding the value of the property.
>And, if the only method is a get-slot method, you wouldn't need to care 
>about whether the property name is an identifier or not. (I'm assuming 
>you're referring to something like 'foo.__getProperty("&propName")'.) 
>Identifier syntax definitions are language-specific, which is something that 
>this interface should probably avoid.

(Continue reading)

Kevin Reid | 2 Aug 21:04 2004

Re: Announcing Release Candidate 0.8.30c: Suggestions Implemented

On Aug 2, 2004, at 14:50, Mark Miller wrote:

> Finally, 'foo::&propName' expands directly to 
> 'foo.__getPropertySlot("propName")'

What is the advantage of foo::&bar over &foo::bar?


Kevin Reid                            <>
Mark Miller | 2 Aug 21:27 2004

Re: Announcing Release Candidate 0.8.30c: Suggestions Implemented

At 03:04 PM 8/2/2004  Monday, Kevin Reid wrote:

>On Aug 2, 2004, at 14:50, Mark Miller wrote:
>>Finally, 'foo::&propName' expands directly to 'foo.__getPropertySlot("propName")'
>What is the advantage of foo::&bar over &foo::bar?

I just found it in the archive!
Thanks to David Hopwood for this suggestion.


Text by me above is hereby placed in the public domain

Kevin Reid | 3 Aug 15:55 2004

Bug (0.8.30b): Nondeterminism leak in BaseAuditor#coerce/2

? interface X {}
# value: X

? 1 :X
# problem: Not audited by org.erights.e.elang.interp.ProtocolDesc <at> c03da9
#   - BaseAuditor#coerce(Object, OneArgFunc)
#   . X.coerce(1, null)
#    <at>  coerce/2
#   - EExpr#evalToPair(Scope)
#   . e`ValueGuard.coerce(X, null).coerce(1, null)`.evalToPair(<a  
#    <at>  evalToPair/1:  


Kevin Reid                            <>
Knut I. Nesheim | 3 Aug 21:11 2004

Re: E [being] insecure

På 28. jul. 2004 kl. 20.06 skrev Mark Miller:

> At 03:11 AM 7/27/2004  Tuesday, Knut I. Nesheim wrote:
>> I'm new to E, and programming in general. I find E to be very 
>> exciting and I
>> would like to learn it.
> Hi Kurt, welcome!
You may call me Kurt if you like to, but my name is really Knut :-)

> The following response may be more detailed than your looking for, but 
> on
> security questions, I prefer to err on the side of completeness first.
> Please let me know if things are still unclear. Thanks.
Somethings are still unclear, but that is because I have problems 
understanding the
terms etc you're using. I am confident this will fix itself given the 

Thank you for your answer! :-)
Knut I. Nesheim
Kevin Reid | 3 Aug 23:33 2004

Complex, rational, and other sorts of numbers in E

Has any thought been given to supporting (or not) complex numbers, 
rational numbers, matrices, etc. in E?

Obviously they can be implemented in E, except that (1 + funnyNumber) 
cannot be made to work (assuming that funnyNumber's value is not 
representable as an E number (if it were, __conformTo would be 
sufficient)), due to the expected security properties.

Perhaps there could be some hook through which additional numeric types 
could be made acceptable to the built-in types' operations, perhaps 
with per-vat/refractive scope?

(I realize that often expressions can be rewritten to place the 
more-accepting type as the receiver. This is not always possible (**, * 
sometimes, /, %), and also would lead to unnecessarily obscure code in 
cases where all of the numbers involved are reliable (e.g. they have 
all passed argument guards)).


Kevin Reid                            <>
Kevin Reid | 4 Aug 01:15 2004

Bug (0.8.30b): Typed FlexMap doesn't try to coerce its keys

? def fm := [].asMap().diverge(String, String)
# value: [].asMap().diverge()

? fm.put("a", "b")
? fm
# value: ["a" => "b"].diverge()

? fm.put("c".asFrom("file:///example"), "d")
# problem: <ArrayStoreException>
#   - FlexMap#put(Object, Object)
#   . ["a" => "b"].diverge().put("c", "d")
#    <at>  put/2: <-.e#:span::4:3::4:5>
#   - EExpr#evalToPair(Scope)
#   . e`fm.put("c".asFrom("file:///example"), "d")`.evalToPair(<a  
#    <at>  evalToPair/1:  

? interp.setShowJStack(true)
? fm.put("c".asFrom("file:///example"), "d")
# problem: <ArrayStoreException>
#   java.lang.ArrayStoreException
#       at  
#       at  
(Continue reading)

David Hopwood | 4 Aug 04:39 2004

On kernel-E, operators, and properties (part 2)

Mark Miller wrote:
> At 03:04 PM 8/2/2004  Monday, Kevin Reid wrote:
>>On Aug 2, 2004, at 14:50, Mark Miller wrote:
>>>Finally, 'foo::&propName' expands directly to 'foo.__getPropertySlot("propName")'
>>What is the advantage of foo::&bar over &foo::bar?
> I just found it in the archive! 

That reminds me, I never got around to "part 2" of this post. Part 2 was going 
to be about a generalisation of slots -- basically allowing a slot to refer
to a set of possible values -- in order to support Oz-style constraint

This would also have unified types and constraints along the lines described 
in .
(I found a way to fix the "it is possible for a program to work by accident"
and "loosening a type declaration can change the behaviour of a correct
program" problems listed under "Cons:".)

I've decided that this needs more work, and that I don't know enough about
constraint programming yet to make a more concrete proposal, but I definitely
intend to return to this subject at some point.

Getting back to simple slots, my earlier post proposed the following
expansions, in addition to the ones corresponding to new features of E 0.8.30:
(Continue reading)

David Hopwood | 4 Aug 08:14 2004

Re: Complex, rational, and other sorts of numbers in E

Kevin Reid wrote:

> Has any thought been given to supporting (or not) complex numbers, 
> rational numbers, matrices, etc. in E?

Thanks for prompting me to finish writing up the following idea, which I
call "lexical arithmetic".


Different applications need different arithmetics. An "arithmetic" is a
set of rules for use of arithmetic operators (+, -, *, etc.):

  - whether results are computed exactly or using rounding; if the latter,
    which rounding?
  - the response to underflow, overflow, loss of precision, invalid
    operations, etc.
  - fixed or floating arithmetic, and normalization issues
  - the behaviour of "special" values such as NaN, -0, and infinities,
    if supported
  - which mathematical structure operations are closed with respect to
    (for example can functions of non-complex arguments return complex
  - accuracy and repeatability requirements
  - how additional kinds of "number" are supported.

No single arithmetic is adequate. For example sometimes it is necessary
to compute exact unrounded rational results; in other cases this would
cause a "precision explosion" in which the amount of time and memory needed
increases exponentially with each operation.
(Continue reading)

Jonathan A Rees | 4 Aug 18:28 2004

Re: Complex, rational, and other sorts of numbers in E

   Date: Wed, 04 Aug 2004 07:14:44 +0100
   From: David Hopwood <david.nospam.hopwood@...>


   Assume a language with nested lexical scoping. For each arithmetic
   operator define an expansion such as

      a + b  -->  __arithmetic.add(a, b)
      a - b  -->  __arithmetic.subtract(a, b)
      -a     -->  __arithmetic.negate(a)

     - could possibly be viewed as too flexible?

     - different from what any other language does.

Not quite *any* other language - Scheme has used this solution for
over 20 years, and the ability to override (usually to extend) + and
friends definitely gets used.  It's not considered dangerous or
confusing as far as I know, maybe because users expect this kind of

Maybe this is cheating since Scheme doesn't have infix syntax and it's
therefore sort of trivial that this would work.

(Continue reading)