dotgnu-visionaries
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Visionaries] WebScheme, the Next Thread(eration)


From: Peter Minten
Subject: [Visionaries] WebScheme, the Next Thread(eration)
Date: Tue, 20 May 2003 13:27:03 +0200

Hi folks,

I noticed that I tend to use metadata attributes for setting field fields.
That's not exactly the Right Thing. That's why I'm now introducing attributes.
An attribute is roughly put the foo in a [foo bar] construction. There are three
kinds of attributes:
* field metadata (@) ()
* value metadata ($@) ($)
* field fields (.)

The things in parenthesises are new ways to call them. Some examples:
[foo] //field metadata foo
address@hidden //<=> [foo]
[$foo] //value metadata foo
address@hidden //value metadata foo
[foo "bar" "baz"] //field metadata which is constructed with two args
[.domain '(value > 10)] //field field, see below for details on domain

Note that I'm dumping the foo^ suffix notation and replacing it with the
equivalent $foo prefix notation, thus $foo -> (get-value foo).

Some terminology:
* metadata attribute refers to something like address@hidden or address@hidden
* field attribute refers to a setter of a field field [.foo]
* field metadata attribute refers to something like [foo] or address@hidden
* value metadata attribute refers to something like [$foo] or address@hidden

Note that the standard fields of a field (of a Binding) are defined in
<binding>.

--

Doing some research into the field of metaprogramming an idea hit my head about
how to make programming in WebScheme both safer and easier. One of the most
boring works of normal programming languages is the guarding of variable domain
(has a variable an allowed value?). Guarding variable domains is very important
for the correct execution of a program, but having to program every domain
checker by hand time and time again tends to promote sloppyness and thus bugs.

WebScheme solves this by introducing the concept of Domains. A Domain is an
object of class <domain> that contains one lambda expression that takes one
argument (usually named 'value') and returns #t if the value is allowed and #f
if it isn't. Bindings (fields) can have explicit domains, this is done with the
field attribute [.domain domain-obj] where domain-obj is a Domain. It is
impossible to give a field a value that is not allowed by it's domain, trying to
do so results in a Domain-violation-exception (obj of
<domain-violation-exception>). 

Domains have two constructors:
(<domain.new> lambda-expression)
(<domain.new> quoted-list)

In the last variant 'value' is automatically used for the value.

Domains can also be used at the entrance of functions, in the parameter clauses
the following is allowed (lambda ((a <vector>) (b (Domain.new (lambda (value)
(or (>= b 1) (<= b 10))))). This in turn can be rewritten into:
(lambda ((a (Domain.new (lambda (value) (= value.class <vector>)))) (b
(Domain.new (lambda (value) (or (>= b 1) (<= b 10))))).

Of course such things don't look very nice. That's why the following notations
are allowed:
(a class-obj) ;; Check if a is an object of class class-obj
(a domain-obj) ;; Using domains
(a (lambda (value) condition)) ;; Domain constructor automatically called
(a '(condition)) ;; Domain constructor automatically called

The real power of domains lies in the reusability. For often used checks you
only need to create a Domain object once and then you can use it basically
everywhere.

Greetings,

Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]