www.digitalmars.com         C & C++   DMDScript  

D - FOOPS Language

reply Mark Evans <Mark_member pathlink.com> writes:
FOOPS
http://www.cs.ucsd.edu/users/goguen/sys/foops.html
http://www.cs.ucsd.edu/users/goguen/ps/foopsman.ps.gz

The module and functional/OO themes are the highlights.  -Mark


"FOOPS is the result of a unification of the functional and object-oriented
programming paradigms.  Given its support for modules and their interconnection,
another way to look at FOOPS is as bringing state-of-the-art module technology
to object orientation."

"Current object-oriented languages take as their main programming unit a
syntactic construction for the definition of a single class with its associated
attributes and methods.  While this simplifies language design, it is
nevertheless a step backwards from the advances introduced by languages such as
Ada, Modula-2, OBJ, Standard ML, and many others in supporting the more general
construction, which allows several related kinds of data and operations to be
declared together.  In FOOPS, modules are the main programming unit."

"FOOPS supports a development method that is unique, to the bet of our
knowledge."

"When the language of a particular application domain can be readily used in a
specification, programs are easier to read and to write.  Towards that end,
FOOPS allows each function to be given a 'syntactic form' that describes whether
the function is to be referred to in infix, prefix, postfix, outfix or, in
general, mixfix syntax.  Also, function names may be overloaded."

"Sometimes static type-checking is too restrictive because it rejects
expressions that, while not completely well-formed, could achieve a correct type
at run time.  On the other hand, dynamic typing is too liberal, allowing truly
nonsensical expressions to go undetected until run-time....  To provide a middle
ground, the FOOPS type checker does as much static typing as possible, but gives
'the benefit of the doubt' to certain expressions that show the potential of
becoming type correct as evaluation proceeds."

"...metaclasses are provided.  These are lists of the current objects of a
certain class, and may be used to effect changes on groups of objects of the
same class.  Furthermore, object modules may declare abstract data types."

"In FOOPS modules can be parameterised (or generic) over very general interfaces
which both include syntactic information and express the properties required of
actual parameters for meaningful instantiation."

"While much work in object-orientation has concentrated on issues such as
low-level type systems, not enough attention has been devoted to the study of
system-level phenomena, such as overall structure, large-grain properties,
sub-component compatibility, variants and configurations.  However, FOOPS
addresses these concerns.
FOOPS is equipped with facilities for reusing and interconnecting modules,
including renaming, summation, parameterisation and instantiation."

"The official semantics of FOOPS is based on reflection in the weak sense of
having a built-in data type for FOOPS programs in its functional sublanguage.
The main advantage of this approach is that reflection reduces all computations
over a FOOPS program to equational deduction.  The deduction system for
reflection provides an operational semantics for FOOPS and allows one to claim
that FOOPS, and hence object-oriented programming, can be considered as logical
in the sense that programs are sentences in a logical system, and computation is
a form of deduction in such a system."
May 04 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
It looks like they've unified the module and templates into one thing.

It sounds hella good for the most part.

Where on earth do you find this stuff?  It looks like I won't have to wait
long for a replacement of C++.  Alot of thought is being applied to these
problems.  Solutions are starting to appear.

consider a potential D version:

implicit S cast<S> ( T a )
{
    return (S)a;
}

T add<numeric T> ( T a, T b );
T mul<numeric T> ( T a, T b );

T mul<numeric T> ( T a, const T b)
{
    return add(mul(a, b/2), mul(a, b - b/2)); // depends on compiler
optimizing common subexpressions
}

T mul<numeric T> ( T a, T 0 )
{
    return T(0);
}

T mul<numeric T> ( T a, T 1 )
{
    return a;
}

T mul<numeric T> ( T a, T -1 )
{
    return -a;
}

T mul<numeric T> ( T a, T 2 )
{
    return add(a, a);
}

T add<numeric T> ( T a, T 0 )
{
    return a;
}

float mul ( float a, float b ) { asm { fmul a, b; ret st(0) } }
int mul ( int a, int b ) { asm { imul $R31, a, b; ret $R31 } }

int add ( int a, 1 ) { asm { inc $R31, a; ret $R31 } }
int add ( int a, -1 ) { asm { dec $R31, a; ret $R31 } }

float add ( float a, float b ) { asm { fadd a, b; ret st(0) } }
int add ( int a, int b ) { asm { add $R31, a, b; ret $R31 } }

float madd ( float a, float b, float c ) { asm { pfmadd $PFR0, a, b, c; ret
$PFR0 } }

float madd ( const float a, float b, float c ) { return add(mul(a,b),c); }
float madd ( float a, const float b, float c ) { return add(mul(a,b),c); }
float madd ( float a, float b, const float c ) { return add(mul(a,b),c); }

implicit T <numeric T> T a * T b
{
    mul<T>(a, b)
}

implicit T <numeric T> T a + T b
{
    add<T>(a, b)
}

implicit T <numeric T> T a * T b + T c
{
    madd<T>(a, b, c)
}
Unify templates and inline assembler.

You will notice that I am using literals as template and function
overloading specializors.  Compile time constants could be useful there as
well.

One would need a  much better way of resolving usage conflicts within the
language though.  One of the biggest portability hassles is what to do when
one vendor does something some way and other vendors do it another way.  In
C++ you must then wrap the thing in #define's to fix it, change all your
calls to use some other name, stuff like that.  It'd be nice to be able to
patch implementation details inside our program, in one place in our code,
instead of having to fix the problem at every instance of the problem in the
codebase.  If the basic syntax of the language were built this way, you
could go all the way up.  Provide new specializations and where there's
conflicts, specify which one to use (you can override this at module level,
or during import).  So if you don't want somebody's low-level language hacks
you can choose not to import them.  Or you can bypass them selectively by
providing alternate implementations or importing a different module which
has them, and hides the others.

using myalgebra<T>.T * T + T;

As someone said, (FOOPS? yeah, the 4th quote below) syntax decisions are
best left in user/client space.  It is impossible to predict how someone
will want to construct data, solve problems, or represent problem structures
in code.  People want infinite customization ability.  We should give it to
them, if we can.

Sean

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:b92im2$dgu$1 digitaldaemon.com...

 FOOPS
 http://www.cs.ucsd.edu/users/goguen/sys/foops.html
 http://www.cs.ucsd.edu/users/goguen/ps/foopsman.ps.gz

 The module and functional/OO themes are the highlights.  -Mark


 "FOOPS is the result of a unification of the functional and


object-oriented

 programming paradigms.  Given its support for modules and their


interconnection,

 another way to look at FOOPS is as bringing state-of-the-art module


technology

 to object orientation."

 "Current object-oriented languages take as their main programming unit a
 syntactic construction for the definition of a single class with its


associated

 attributes and methods.  While this simplifies language design, it is
 nevertheless a step backwards from the advances introduced by languages


such as

 Ada, Modula-2, OBJ, Standard ML, and many others in supporting the more


general

 construction, which allows several related kinds of data and operations to


be

 declared together.  In FOOPS, modules are the main programming unit."

 "FOOPS supports a development method that is unique, to the bet of our
 knowledge."

 "When the language of a particular application domain can be readily used


in a

 specification, programs are easier to read and to write.  Towards that


end,

 FOOPS allows each function to be given a 'syntactic form' that describes


whether

 the function is to be referred to in infix, prefix, postfix, outfix or, in
 general, mixfix syntax.  Also, function names may be overloaded."

 "Sometimes static type-checking is too restrictive because it rejects
 expressions that, while not completely well-formed, could achieve a


correct type

 at run time.  On the other hand, dynamic typing is too liberal, allowing


truly

 nonsensical expressions to go undetected until run-time....  To provide a


middle

 ground, the FOOPS type checker does as much static typing as possible, but


gives

 'the benefit of the doubt' to certain expressions that show the potential


of

 becoming type correct as evaluation proceeds."

 "...metaclasses are provided.  These are lists of the current objects of a
 certain class, and may be used to effect changes on groups of objects of


the

 same class.  Furthermore, object modules may declare abstract data types."

 "In FOOPS modules can be parameterised (or generic) over very general


interfaces

 which both include syntactic information and express the properties


required of

 actual parameters for meaningful instantiation."

 "While much work in object-orientation has concentrated on issues such as
 low-level type systems, not enough attention has been devoted to the study


of

 system-level phenomena, such as overall structure, large-grain properties,
 sub-component compatibility, variants and configurations.  However, FOOPS
 addresses these concerns.
 FOOPS is equipped with facilities for reusing and interconnecting modules,
 including renaming, summation, parameterisation and instantiation."

 "The official semantics of FOOPS is based on reflection in the weak sense


of

 having a built-in data type for FOOPS programs in its functional


sublanguage.

 The main advantage of this approach is that reflection reduces all


computations

 over a FOOPS program to equational deduction.  The deduction system for
 reflection provides an operational semantics for FOOPS and allows one to


claim

 that FOOPS, and hence object-oriented programming, can be considered as


logical

 in the sense that programs are sentences in a logical system, and


computation is

 a form of deduction in such a system."
May 04 2003