Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP

Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP

[Richard Riehle]

"Cristiano Sadun" <cristianoTAKEsadun@THIShotmailOUT.com> wrote in message
news:Xns954B81678A9D6cristianosadunhotmai@130.133.1.4...
> brangdon@cix.co.uk (Dave Harris) wrote in
> news:memo.20040819213812.1988A@brangdon.m:
>
> > I notice you mention, "different primitive types". I suspect a fair
> > fraction of type errors in C/C++ are due to mixing up the integers,
> > int versus short versus long versus bool versus char versus wchar_t
> > versus unsigned. Sometimes it's useful to have that much control, but
> > often it just gets in the way and makes opportunity for mistakes.
>
> Hm. It could be - but just why you should want to declare something as,
> say, short, if it isn't necessary? If int or long fit all your
> situations, just declare everything as int or long.
>
1)  In languages that support automatic type promotion,
     one is always at risk.

2)  Type casting needs to be more disciplined in some of
      those languages.

3)  When I declare a type, with a given bounds, it allows the
      compiler to check whether I any objects of that type,
      when used within my program, are likely to be out of
      bounds (above or below the given range).  For example,
      (in Ada)

      type T1 is range -473 .. 451;
      type T2 is digits 7 range -30_000.0 ... 100_000.0;
      type Unsigned_Small_Integer is mod 256;
      for Unsigned_Small_Integer use 8;

      I could give many more examples some of which would
      illustrate the ability to create types of quite sophisiticated
      properties.

In type T1, I have defined a type with a given upper and lower
bounds.   The compiler can use this information.   Also, every
Ada program sits on top of a small run-time executive.  The
RTE is tiny, but it does its job well.   When something occurs
that causes an object of type T1 to go out of bounds (not
common, but possible), the RTE raises a constraint error.

In the case (contrived, I admit) of Unsigned_Small_Integer, we
have an unsiged integer that can be represented in eight bits. I
use a representation clause (for ... use 8) to force the size
of the representation eight.  I could just as easily force the
size to 16 bits or 32 bits, and then specified the alignment
I want for objects of that type.   If I make an error, the
compiler immediately notifies me of it.

Granted, when writing programs for less critical systems, these
features can be overkill. For a large category of embedded,
real-time systems, particularly those targeted to bare-board
environments), these features are a blessing.

As several people have noted, it is not (or should not be) a
debate about the virtues of static typing over non-static
typing.  Rather the discussion should be about when it is
appropriate to use static typing (if often is) and when it
is appropriate, as it often is, to use non-static typing.  It
should not be a debate about Smalltalk or Lisp, at one
extreme, versus Ada, at the other the other extreme.
Instead, it should be the case that we all learn the tools
of our profession, understand when to use which tool,
and not be so dogmatic about one tool over another,
that we fail to understand the advantages of each tool
in different circumstances.

I personally like Smalltalk.  I like, but am not proficient
in Lisp. I have seen enough successful software in both
languages to have respect for both the developers and
the languages.   At least one Smalltalk afficionado of
my acquaintance is smart enough to understand that
Smalltalk has its limitations for certain classes of
problems.   I readily admit that Ada may not always
be the right solution.  Of course, I continue to believe
that there is no situation where I would deliberately
choose C++, so I guess I am a bit inflexible in that
regard.   That is, if I have a choice of Ada versus
C++, I would almost always choose Ada.  On the
other hand, if there were choice between Ada and
Smalltalk, Ada and Eiffel, Smalltalk and Lisp, Perl
and Eiffel, etc., I would want to evaluate the context,
the circumstances, the architecture, and many other
considerations before making a decision.    Does that
not seem a sensible approach?

Richard Riehle

Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP

[Programmer Dude]

Richard  Riehle writes:

> As several people have noted, it is not (or should not be) a
> debate about the virtues of static typing over non-static
> typing.  Rather the discussion should be about when it is
> appropriate to use static typing (if often is) and when it
> is appropriate, as it often is, to use non-static typing.  It
> should not be a debate about Smalltalk or Lisp, at one
> extreme, versus Ada, at the other the other extreme.
> Instead, it should be the case that we all learn the tools
> of our profession, understand when to use which tool,
> and not be so dogmatic about one tool over another,
> that we fail to understand the advantages of each tool
> in different circumstances.

HEAR! HEAR!!
 
> I personally like Smalltalk.

Ditto.  I borrowed some of it's more interesting ideas for my
own language, BOOL.

> I like, but am not proficient in Lisp.

Double Ditto!  Very cool language.

Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP

[Nick Roberts]

On Fri, 20 Aug 2004 12:23:40 -0500, Programmer Dude <Chris@Sonnack.com>  
wrote:

>> I personally like Smalltalk.
>
> Ditto.  I borrowed some of it's more interesting ideas for
> my own language, BOOL.

Would you say a bit more about this language (BOOL), please.

-- 
Nick Roberts

Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP

[Programmer Dude]

Nick Roberts writes:

>>> I personally like Smalltalk.
>>
>> Ditto.  I borrowed some of it's more interesting ideas for
>> my own language, BOOL.
> 
> Would you say a bit more about this language (BOOL), please.

Well, you may be sorry you asked.... here's a post from a while
back to get you started.  If you're still interested, I can say
(much, much) more....

The first section is from the Foreward of the language "book".
What follows is a reply to someone else who asked (and was prolly
sorry they did)....

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Foreword, Forward, Forewarned, Forearmed! [1]

BOOL2000 is a language of a fevered imagination. It's the final
output of years of ruminating, bursts of activity and huge dry
spells. BOOL is at least twelve years in the making, and it has
been through many versions and variations. It's been a bit like
a whittling project I've been working on in my spare time for
years and years!

It was never intended as a serious language, so developing the
spec and the supporting software (for what is a language spec
without at least one compiler?) has never been a serious project.
[...]

BOOL is a labor of love. It is not intended to be a serious
programming language, but as a kind of work of art. Which is
not to say it's a good work of art, just that it's a work of
art. Therefore, you should judge it for its appearance more
than for its utility. Think of it as a sculpture, not an
ideal computer programming language.

[1] Four Words!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So keep that in mind!

> Better it seems would be to have a tag bit on each first-class-
> pointer which says whether it's a literal constant or not,
> and if it is then don't bother with all that overhead.

No, because then the Run Time Engine needs to know about the
contents of the Objects.  It may not.  There is no real difference
between asking a variable numeric Object to place a reference to
itself on the PStack and asking a constant numeric Object to do
the same.  SOMEONE has to do it, and it might as well be the
one who knows the Object best: the Object.

> For example, there can be a tag byte that tells the basic type,
> and the first bit can simply decode whether it's literal
> constant or not, and other bits decode more detailed type info
> used later down the line.

Objects do, in fact, carry some generic state information, and
in this case, a relevant one is the READONLY flag.  In BOOL,
literals are real numeric Objects just like variable numerics
About the only difference is that they are READONLY.

But this state information is enclosed in the Object, the RTE
may not (generally speaking) access it directly.

> As for doing argument evaluation in parallel (when more than one
> argument is something other than a literal constant), here's some
> comments: First, it's bad to have a single stack pointer that is
> directly diddled by several different processes.

Of course.  The PStack is an active singleton Object in the BOOL
environment.  So are the AddressSpace, DataSpace and NameSpace
servers.

> Given that, you could organize it like this:  Your goal is to
> push all evaluated arguments onto the stack before calling the
> primary function (the CAR of the form), right?

Yes, although the verbiage is a little off. There is no primary
function to call.  Once the PStack has the expected values on it,
we send the Message to the Target Object.  In Lisp, we might write
it like this:

	(send-a-message 'ADD Target (list arg1 arg2 ... argN))

The send-a-message function would first push the arguments onto the
PStack.  Then send the ADD message to the Target.  The Target is
responsible for dispatching the message to a handler.  The handler
expects to find the Objects it needs for input on the PStack.

> So it's not a case of pushing several arguments unrelated to each
> other, but it's a case of creating a stack frame which contains
> *all* the various evaluated arguments in correct sequence, and
> then passing that stack frame to the primary function.

Fine up to the last bit.  The "primary function" only takes a message
as input.  Its input data in on the PStack.

> So what you do is create an instance of a stack-frame-builder,
> and tell that object you want for example five slots in this
> frame. Then you tell each of the argument evaluators which
> stack-frame-builder you're using and which stack offset that
> particular argument should use.

No thanks.  Too complex at run time and requires too much information
to be shared within the system.  The RTE borrows from Forth in being
very, very simple.


>> All integers belong to the same class ("Model" in BOOL).  The
>> Model contains a *single* instance of the code necessary to do
>> anything an integer can do.  (All object instances have a
>> reference to their Model, so all "methods" in BOOL are "virtual".
> 
> So each integer object has within it (1) a type-code that says
> what size of integer it really is (16-bit 32-bit bignum whatever),
> (2) the actual data appropriate for that size integer, and (3) a
> link to the class (model) for all integers?

Very close!  It specifically looks like this (BOOL runs within a
virtual environment that (currently) consists of 32-bit "cells"):

    +----+----+----+----+
    |  signature   | TT | 0      (TT == Meta-Class)
    +----+----+----+----+
    |       flags       | 1
    +----+----+----+----+
    |    Name handle    | 2      (handle to NameSpace)
    +----+----+----+----+
    |    Model handle   | 3      (handle to AddressSpace)
    +----+----+----+----+
    |     data area     | 4,5,6,7
    +----+----+----+----+

ALL BOOL instance Objects (i.e. "data") have basically the same
first four cells (obviously, the flags, name and Model will have
different values).  BOOL has less than a dozen "meta-classes" of
which **everything** is an instance.  There is a Model meta-class,
an Action meta-class, etc.  All instance Objects belong to the
Instance meta-class, therefore all such have the same "TT" value.
Instance Objects of different types (e.g. strings, real numbers,
integer numbers, user-defined types) will have a different Model
(the fourth cell).

Each Meta-class has an Executive that handles Messages sent to
objects of its class.  The Executives, like the RTE, are designed
to be as simple as possible and generally handle only very basic
Messages.  The real meat is in the Actions of each Model for
each defined *type*.

The data area, up to four bytes, is used as required by the Model
("type") and *flavor*.  For instance, the BOOL integer type has
four basic flavors: 32-bit, 64-bit, 96-bit and 128-bit.  Each of
these has signed and unsigned flavors.  (Flavor information is
kept in the flags cell.)  Models with more than 128 bits of data
use the data area to keep a handle to the actual data in the
Data Space.

You'll note that BOOL Objects keep their name even after compiling.
A BOOL Image *can* be (more or less) fully decompiled (comments
are lost).

Whew.... anyway....

> So if you want to add an integer and some other kind of number,
> depending on which sequence you place the two numbers, it might
> pass the task to the integer model or to the other-kind-of-number
> model, which would then have to notice what the other argument
> was, and in the end both cases go to the code for coercing one
> to the other type and doing the operation?

Not quite.  The Target Object would need to examine its parameter
Object(s).  Let's use a real example...

	*int2  n =100   -- {*int2} is an alias for {*int %64}
	*double  d      -- {*double} aliases {*real %64}

	set: d n        -- set the double to the integer
	set: n d        -- set the integer to the double

In the first case, {d} would inspect {n} by sending an internal
Message {M:} asking for its Model. If it knows how to do the
conversion, it will.  If it can't, it will ask if {n} can supply
a representation of {d}'s type.  If {n} replies, "Huh?", then
no conversion is possible, and the attempt fails.

The second case would be the same, but with reversed roles.

So, the proceedure is: (1) check parameter type(s), (2) if
conversion is required AND if we can do it, do it, else (3)
ask if the parameter can do it, and if that fails (4) throw
an exception.


> So in the integer model, for example, there must be code to
> dispatch depending on what message class (add, subtract,
> multiply, divide, power, exp, log, sine, cosine, etc.)...

Message *name*, but yes.  There are the Messages add:, sub:,
mul: div: pow: exp: log: sin: cos:, etc.  There is an Action,
owned by the *int Model, that handles each Message.  That is,
performs an integer operation on integers.

> ...and what type the other argument is?

No.  The other argument must be of the same type.  For example here,
integers would (probably) know how to make an integer from any other
numeric Model (likewise, reals would know how to make a real).  Any
operation depending on a parameter is responsible for testing and
coercing that parameter.  Per above, it can request the parameter's
help.

> How is this better than the LISP way, where a generic function is
> called which already knows what arithmetic operation is to be
> performed, but it must dispatch on the types of each of the two
> arguments?

?!?!  Who said it had to be better??  ;-)