🚀 go-pugleaf

In article <ROCKWELL.92Apr9233337@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> [... I want to be able to declare conventional variables ...]
|> Define yourself a verb to modify X.  If you're really paranoid, you
|> can write yourself a routine which does a static analysis of the
|> program text to find any instances where X is modified without the use
|> of this access verb.  If you need to do this sort of thing frequently,
|> you can call this routine a tool.

Well, I think it's rather a pain to have to go to such trouble for 
such a simple and common feature.  Simple things should - if common -
be simple to do.

|> [...]
|> I meant that if you compile a function to take only integer arguments
|> that you won't be able to pass to it arguments representing fractional
|> numbers.  The idea is that this is a restriction imposed during
|> compilation, and is not a property of the code.  Of course, you might
|> consider compiler invocation parameters to be code.

Yes, this is what I want.  Can you give an example of how to do it
that's actually statically checked?

|> [...] Then you can tell me the very thing I keep asking and you
|>    keep dodging - how do I declare that a given identifier has a
|>    specific type for the life of the program - yet its _value_ can
|>    change?
|> 
|> I think I'd define an accessor verb.

That's fine to guard accesses.  How do you guard against reassignments?
Note, the `colon' definitions you described earlier prevent the identifier
from being reassigned at all.  What I want is to allow the _value_ to 
be assigned without allowing the type to ever be alterred.

|> [...]
|> Either that or just do a global search for all instances of that name
|> [though this seems, to me, more useful for maintenence than for
|> design].

This is exactly the kind of search I _don't_ have to make if all the 
type declarations are in the header of the current procedure or module.

J. Giles