[M3devel] small array in modula-3?

[Rodney M. Bates]

Jay wrote:
> Rodney, thank you, this is interesting.
> I definitely don't want to pay for heap allocation for a tiny array.
> I don't know about "subarray". It looks like it takes and returns 
> arrays. It's not a type. I ordered another copy of the Nelson book so I 
> don't have to find mine.

SUBARRAY is an expression.  It accesses a subrange of the elements of
an array.  You can use it on the left of assignment or on the right.

>  
> Good idea "MakeT" I forgot about that pattern. I'll try it out.
>  
> The record and array I propose are not all that different really.
> I just heard of something new. Have you heard of it? "Duck typing". If 
> it acts/quacks/walks like a duck, it is a duck.
> This is in very dynamic languages like Ruby.
> You apply object.method and if object defines something named "method", 
> then it "must" have "the" meaning you intend.
> Kind of like how C++ templates "accept as parameters whatever happens to 
> work".

This kind of thinking about software will work sometimes, but it's a recipe
for disaster overall.  It's quite too hard already to get the bugs out of
software without people invoking things with only a guess what they mean.
"If it looks like a duck ..." is absolutely not reliable in software.
That's also the problem with over complex languages: people write massive
amounts of code with only guesses about what the language constructs mean.

>  
> Operator overloading is great for strings and "math".
>  
> Maybe I should try to have this language debate from scratch again..?
>  
> I still am conflcted.
>  
> Modules seem overly heavyweight.
> I don't want Module1.T, Module2.T, I want T1, T2.

; IMPORT Module1
; IMPORT Module2
...
; TYPE T1 = Module1 . T
; TYPE T2 = Module2 . T

Now you can use T1 and T2 all over the place.  Of course, if
it weren't for two modules each having a different T, you could
just say FROM Module1 IMPORT T, so T is available without qualification,
but unlike above, is not renamed.

(This is pasted in from Jay's other post on this topic)

 >But if I don't want to pay for heap allocation, I can't say:

 >VAR T: v;

 >v.DoSomething();

 >Only IMPORT T FROM M;

 >VAR T: v;

 >M.DoSomething(v);

 > Right?

If you don't want to have to write the module name as a qualifier, you can
rename a procedure too, with a constant declaration (Procedures in Modula-3
are actually the same thing a constants of procedure type.)

CONST DoSomething = M.DoSomething
...
DoSomething ( v )

Having been almost forced (for other reasons I'll skip for now) in Ada to
consistently use qualified references like M.DoSomething, I've come to
believe that is the right way to code, even though it's more writing.  It
makes old code/somebody else's code _much_ easier to read.  Using unqualified
names is turning the priorities upside-down and saying writability trumps
readability.

Only if it's referred to _very_ often, do I use unqualified names (in which
case, I also make them short).  One limitation in Modula-3 is that you can't
rename an exception or (well, not in the most general way) a variable from
an imported module.  I discussed this once in a list of language wants,
but expressed ambivalence, particularly about variable renames.

>  
> C++ stack structs with non virtual member functions:
> class Rect_t
> {
>   Rect_t() : top(0), left(0), right(0), bottom(0) { }
>  
>    int Height() { return bottom - top; }
>    int Width() { return right - left; }
>    int top, left, bottom, right;
> };

The nonvirtual member functions greatly complicate the language,
and provide nothing that plain, nonmember functions don't provide.

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu