[M3devel] small array in modula-3?
Mika Nystrom
mika at async.caltech.edu
Fri Nov 16 23:07:13 CET 2007
Naw, it's
DoSomething(x);
DoSomethingElse(y)
It's not the same function. Not even in C++! It's just another
example of overloading...
Jay writes:
>--_85b6c041-9539-4614-b541-8813489e58bb_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>> VAR v : T;> DoSomething(v);> > What's the big deal if it's DoSomething(v)=
> or v.DoSomething()? VAR x : T1; VAR y : T2; DoSomething(x); DoSomething(y)=
>;
>isn't legal, right?
>=20
>So I have to:
> M1.DoSomething(x); M2.DoSomething(y);
>right? Constantly repeating types, or modules, on function names?
>=20
> - Jay
>=20
>
>
>
>> To: jay.krell at cornell.edu> Subject: Re: [M3devel] small array in modula-3=
>? > Date: Thu, 15 Nov 2007 21:00:13 -0800> From: mika at async.caltech.edu> > =
>Why not > > FROM M IMPORT T, DoSomething;> > VAR v : T;> DoSomething(v);> >=
> What's the big deal if it's DoSomething(v) or v.DoSomething()?> > If anyth=
>ing, "DoSomething(v)" tells me that the call can be statically> resolved, w=
>hereas v.DoSomething() tells me that something odd can> happen at runtime--=
>-that is, I cannot be sure I understand this> code simply by looking for a =
>routine called "DoSomething" and reading> that, but have to be more careful=
>. This distinction is unclear in> C++. What, in fact, is the distinction in=
> C++ between DoSomething(v)> and v.DoSomething()? None, right? Just two way=
>s of saying the> same thing... why?> > The Modula-2+ work on the Firefly is=
> also close enough to be "almost"> Modula-3...> > Regarding UNSAFE: most in=
>terfaces to C code are (or should be)> UNSAFE because there are ways of cal=
>ling them that can lead to> unchecked runtime errors. I don't see how you c=
>an live without> UNSAFE if you ever want to link with other people's C libr=
>aries...> > Mika> > Jay writes:> >--_0109391c-2ffe-4cfe-9165-c2a24628c3c7_>=
> >Content-Type: text/plain; charset=3D"iso-8859-1"> >Content-Transfer-Encod=
>ing: quoted-printable> >> >But if I don't want to pay for heap allocation, =
>I can't say:> >=3D20> >VAR T: v;> >=3D20> >v.DoSomething();> >=3D20> >Only =
>IMPORT T FROM M;> >=3D20> >VAR T: v;> >=3D20> >M.DoSomething(v);> >=3D20> >=
>Right?> >SPIN I think you mean.> >Anyone build it and bring it up? I was lo=
>ng curious but never did..> >=3D20> > - Jay> >> >> >> >> CC: m3devel at elegos=
>oft.com> From: darko at darko.org> Subject: Re: [M3devel] =3D> >small array in=
> modula-3?> Date: Thu, 15 Nov 2007 20:29:06 -0800> To: jay.kr=3D> >ell at corn=
>ell.edu> > Not sure what the problem is with modules. If you want t=3D> >o =
>avoid the > dot you can name the type something unique then import that t=
>=3D> >ype > name. You can create an interface with all the nice type names =
>and > =3D> >import all those names in modules by adding an EXPORTS clause t=
>oo.> > Perso=3D> >nally I think M3, with a couple of extensions, wouldn't n=
>eed > unsafe anyth=3D> >ing. The unsafe features are there mostly because o=
>f > legacy interfaces. I=3D> > forget the name but the folk who wrote an OS=
> in > M3 found it very effecti=3D> >ve with only couple of minor points wit=
>h > regards to interfacing to C code=3D> > they built on top of, I think on=
>e of > them was being able to pass NIL to =3D> >a VAR parameter, which is a=
> common > C idiom (and an annoying one for M3 us=3D> >ers who then can't us=
>e VAR).> > > On 15/11/2007, at 8:08 PM, Jay wrote:> > =3D> >> Rodney, thank=
> you, this is interesting.> > I definitely don't want to pay=3D> > for heap=
> allocation for a tiny array.> > I don't know about "subarray". It=3D> > lo=
>oks like it takes and returns > > arrays. It's not a type. I ordered ano=3D=
>> >ther copy of the Nelson book > > so I don't have to find mine.> >> > Goo=
>d i=3D> >dea "MakeT" I forgot about that pattern. I'll try it out.> >> > Th=
>e record =3D> >and array I propose are not all that different really.> > I =
>just heard of s=3D> >omething new. Have you heard of it? "Duck typing". > >=
> If it acts/quacks/wa=3D> >lks like a duck, it is a duck.> > This is in ver=
>y dynamic languages like Ru=3D> >by.> > You apply object.method and if obje=
>ct defines something named > > "m=3D> >ethod", then it "must" have "the" me=
>aning you intend.> > Kind of like how C=3D> >++ templates "accept as parame=
>ters whatever > > happens to work".> >> > Ope=3D> >rator overloading is gre=
>at for strings and "math".> >> > Maybe I should try=3D> > to have this lang=
>uage debate from scratch again..?> >> > I still am conflc=3D> >ted.> >> > M=
>odules seem overly heavyweight.> > I don't want Module1.T, Modu=3D> >le2.T,=
> I want T1, T2.> >> > C++ stack structs with non virtual member funct=3D> >=
>ions:> > class Rect_t> > {> > Rect_t() : top(0), left(0), right(0), bottom(=
>=3D> >0) { }> >> > int Height() { return bottom - top; }> > int Width() { r=
>eturn =3D> >right - left; }> > int top, left, bottom, right;> > };> >> > se=
>ems "good".>=3D> > >> > And it seems not really all that complicated for th=
>e compiler to > > =3D> >flow the static type information around to resolve =
>the functions..> >> > Re=3D> >ct_t r;> > r.Height() =3D3D> Rect_Height(&r);=
> ..and would be inlined anyway.>=3D> > >> > I do find some compelling featu=
>res in Modula-3. Mainly that it > > co=3D> >mpiles to native code and has O=
>PTIONAL safety, optional garbage > > collect=3D> >ion, and that the syntax =
>of modules/interfaces allows fast > > compilation =3D> >-- no longer repars=
>ing the same headers over and over > > and over and over=3D> >.> >> > Opera=
>tor overloading btw..have seen "template SafeInt"? It acts > >=3D> > like a=
> primitive integer, but raises exceptions upon overflow.> > For this=3D> > =
>to work very much requires operator overloading.> >> > A point, of course,=
>=3D> > is to be able to have user defined types that > > can act like the b=
>uilt i=3D> >n types..> >> > - Jay> >> >> > > Date: Thu, 15 Nov 2007 18:39:1=
>8 -0600> > >=3D> > From: rodney.bates at wichita.edu> > > To: m3devel at elegosof=
>t.com> > > Subject=3D> >: Re: [M3devel] small array in modula-3?> > >> > > =
>Jay wrote:> > >> > > > W=3D> >hat is the right way to have a variably sized=
> but always small > > array in=3D> > Modula-3?> > > > My array will only ev=
>er have 1 or 2 elements.> > > > I'd =3D> >like to always allocate room for =
>2 elements, and have there > > be a size.>=3D> > > > >> > > > It seems I ha=
>ve a choice of> > > >> > > > a) an "open" array>=3D> > > >> > > Heap alloca=
>ted, I presume? If the max size is only 2 elements,> >=3D> > > this is pret=
>ty extravagant, as a heap allocated open array will> > > hav=3D> >e 4 extra=
> behind-the-scenes words of space overhead, plus> > > maybe heap f=3D> >rag=
>mentation, and time overhead of allocation,> > > collection, and maybe r=3D=
>> >educed locality of reference.> > >> > > > b) wrap it up in a record> > >=
> >>=3D> > > > > I'd like so have, like:> > > >> > > > TYPE A =3D3D ARRAY [0=
>..1] OF FOO=3D> >;> > > >> > > > And be able to say:> > > >> > > > VAR> > >=
> > a : A;> > > >>=3D> > > > > ..> > > > a.size> > > > FOR i :=3D3D 0 TO a.s=
>ize DO> > > > do somethin=3D> >g with a[i]> > > >> > > > It seems I have no=
> option but, like:> > > >> > > =3D> >> TYPE A =3D3D RECORD> > > > a: ARRAY[=
>0..1] OF FOO;> > > > size :=3D3D 1; (* us=3D> >ually of size 1, sometimes 2=
> *)> > > > END> > > >> > > > and then> > > > FO=3D> >R i :=3D3D 0 TO a.size=
> DO> > > > do something with a.a[i];> > > >> > > > That=3D> > is "ok". Not =
>great -- what to call the inner a?> > > > But then furthermor=3D> >e, I'd l=
>ike to construct constants.> > > > It seems I am stuck with either =3D> >th=
>e verbose:> > > >> > > > PROCEDURE F(a:A);> > > >> > > > F( A { ARRAY[0..=
>=3D> >1] OF FOO { .. } );> > > >> > > > OR I have to come up with a name fo=
>r the =3D> >embedded array.> > > > But of course, its type is really "the s=
>ame" as the =3D> >outer type.> > >> > >> > > Ignoring the fact that the typ=
>es are different l=3D> >inguistically> > > (one a record type, the other an=
> array), the types are d=3D> >ifferent> > > at a deep semantic level too. T=
>he inner array has static> > >=3D> > size, the outer one (call it a "variab=
>le array", perhaps)> > > has dynamic=3D> >ally changeable size, even more e=
>asily changed> > > after it is created tha=3D> >n a heap-allocated open arr=
>ay. This> > > is a significant semantic differen=3D> >ce, so it also makes =
>program> > > design sense to view them as different ty=3D> >pes.> > >> > > =
>>> > > > To wit:> > > >> > > > TYPE FooArray =3D3D ARRAY[0..1]=3D> > OF Foo=
>;> > > >> > > > TYPE FooArray =3D3D RECORD> > > > a : FooArray;> > > >=3D> =
>> size :=3D3D 1;> > > > END;> > > >> > > > F( FooArray { FooArray { .. } );=
>> >=3D> > > >> > > > But I have to come up with different names.> > > >> > =
>> > And I=3D> > don't think I can leave out the name for the constructor, >=
> > like:> > > >=3D> >> > > > F( FooArray { { .. } );> > >> > >> > > Yes, th=
>is is a limitation in=3D> > Modula-3. Ada allows value constructors> > > to=
> omit inner type names in c=3D> >ases like this, and it is > > convenient. =
>But> > > it also crosses a really=3D> > major line on complexity of the lan=
>guage > > semantics,> > > since type an=3D> >alysis information now flows n=
>ot only upward, but > > also downward> > > in=3D> > expression typing. I am=
> mostly content to live with this as > > one bit of=3D> >> > > the price of=
> avoiding a horribly over complex language.> > >> > > Ord=3D> >inary proced=
>ures can do pretty much all of the things done by > > exotic> >=3D> > > and=
> complex language stuff like C++ constructors. If you don't > > want =3D> >=
>to write> > > the ponderous nested value constructor, write a constructor >=
>=3D> > > procedure and> > > call it. As Antony suggested, you can make it a=
>ccept =3D> >an open > > array formal,> > > which then codes just like a sim=
>ple array va=3D> >lue constructor. You > > could even> > > make it elaborat=
>e and general, e.g=3D> .:> > >> > > PROCEDURE MakeF ( Val : ARRAY OF FOO ) =
>: F> > >> > > =3D3D VAR L=3D> >Size : CARDINAL> > > ; VAR LResult : A> > >>=
> > > ; BEGIN> > > LSize :=3D3D NU=3D> >MBER ( Val )> > > <* ASSERT LSize <=
>=3D3D NUMBER ( FooArray ) *>> > > ; LResul=3D> >t . size :=3D3D LSize> > > =
>; SUBARRAY ( LResult . a , 0 , LSize )> > > :=3D3D S=3D> >UBARRAY ( Val , F=
>IRST ( Val ) , LSize )> > > ; RETURN LResult> > > END Make=3D> >F> > >> > >=
> Alternatively, since your maximum element count is so small, yo=3D> >u > >=
> could> > > write a constructor procedure that took two formals of typ=3D> =
>>e FOO, > > with> > > at least the second one optional. (This would require=
> =3D> >a > > distinguished> > > value of type FOO that would be used to mea=
>n "omit=3D> >ted".)> > >> > > And, of course, if you want to use abstractio=
>n, you can pu=3D> >t the > > types,> > > constructor procedures, and variou=
>s other procedures =3D> >for > > manipulating> > > the variable sized array=
> in a module, behind an i=3D> >nterface.> > >> > > An additional limitation=
> of Modula-3 in this regard, is=3D> > that you > > can't> > > make the type=
> F opaque, unless you heap allocate i=3D> >t, which we > > were trying> > >=
> to avoid. Ada would allow you to do this, =3D> >but it's another > > examp=
>le of> > > a convenience with high cost. It force=3D> >s the equivalent of =
>the > > revelation> > > to be located in the equivalent=3D> > of the interf=
>ace, but makes it > > illegal> > > to write client code that =3D> >depends =
>on what the revelation is.> > >> > > This in turn creates a source =3D> >co=
>de control nightmare in a large > > project,> > > because now someone who=
>=3D> > wants to make what is really a purely > > internal,> > > implementat=
>ion ch=3D> >ange, nevertheless has to check out the > > interface, and> > >=
> if you aren=3D> >'t in denial mode, that means implementers of all the > >=
> client> > > code =3D> >have to go to extra trouble to somehow find out tha=
>t what > > appears> > > =3D> >to be an interface change actually doesn't af=
>fect them after all.> > >> > >=3D> > >> > > > Though that might seem nice.>=
> > > >> > > > Am I understanding eve=3D> >rything?> > > >> > > > Have folks=
> hit this before and there's a set of name=3D> >s that > > don't seem too l=
>ame> > > > that folks use?> > > >> > > > Also --=3D> > language documentati=
>on?> > > > Nelson's green book is excellent.> > > > Th=3D> >e stuff in the =
>doc directory is very dry and scientific.> > > > The tutoria=3D> >l seems m=
>ore like a reference. Or maybe I didn't > > read it enough.> > > >=3D> > Is=
> there better, in case I need a refresher?> > > > I think I got it, via =3D=
>> >Nelson's book from memory (wonder if I > > can find mine..) and the refe=
>ren=3D> >ce,> > > > but I don't think anyone could learn from the current o=
>nline > >=3D> > docs in the source tree.> > > >> > > > Maybe it's me, some =
>combination of =3D> >laziness and short attention > > span> > > > as I age.=
>.> > > >> > > > Btw, =3D> >C doesn't offer a great solution here, though it=
> offers > > leaving out som=3D> >e type names.> > > > In C++ I could have b=
>oth .size and operator[].> > > > =3D> >Modula-3 seems to be missing operato=
>r overloading.> > > > It's got some bui=3D> >ltin stuff, even array assignm=
>ent and equality > > and I think> > > > even =3D> >record assignment and eq=
>uality, but it is still a bit > > limiting.> > >> >=3D> > >> > > I have rav=
>ed on this before, but, having had lots of painful > > ex=3D> >perience wit=
>h> > > user-defined overloading in Ada and C++, I can say with =3D> >> > au=
>thority, that it is> > > a programming language disaster. It interact=3D> >=
>s with just about > > everything> > > else in the language, in very complic=
>=3D> >ated ways, and all it buys > > you is saving> > > time/energy thinkin=
>g up d=3D> >istinct names for procedures/functions. > > Even this,> > > asi=
>de from the =3D> >effects on the language, is a net loss, by the > > time y=
>ou consider> > > r=3D> >eadability along with writability.> > >> > > User-d=
>efined overloaded operat=3D> >ors provide a slight readability > > benefit,=
> _if_> > > used with great res=3D> >traint and discipline, something you ca=
>n rely > > on not happening.> > > Me=3D> >anwhile, the language complexity =
>can easily double or worse. > > And, with =3D> >the> > > exception of compi=
>ler writers and language lawyers who spend > > h=3D> >undreds of hours> > >=
> on just this, programmers don't understand the rules,=3D> > not even > > c=
>lose.> > >> > > >> > > > Also, if I understand things correc=3D> >tly, this=
> has long bothered > > me about Modula-3,> > > > though I'm more t=3D> >ole=
>rant now -- Modula-3 doesn't seem to allow > > for lighter wieght> > > >=3D=
>> > objects. Like, small stack allocated structs with member > > functions.=
> Yo=3D> >u seem to have> > > > to chose between heap allocated garbage coll=
>ected vir=3D> >tual > > member functions full> > > > featured objects, or f=
>eatureless dumb=3D> > structs. It's nice how C+ > > + allow hybrids --> > >=
> > objects don't have=3D> > to be heap allocated and member functions > > d=
>on't have be virtual.> > > =3D> >> Or am I missing something?> > >> > >> > =
>> C++'s supposedly lighter weight=3D> > forms of classes/structs with > > t=
>heir special> > > member functions buy =3D> >nothing that plain records, pl=
>ain > > procedures, and> > > interfaces/modul=3D> >es don't already provide=
>, again, at significant > > and gratuitous> > > lan=3D> >guage complexity. =
>Except when methods/member functions > > actually dispatc=3D> >h> > > dynam=
>ically, there is nothing that the above won't do, and when > > =3D> >you cr=
>eate a> > > class instance as a local variable (i.e., on the stack), =3D> >=
>it is > > necessarily> > > not polymorphic, that is, it can't change its "a=
>=3D> >llocated" or > > dynamic type> > > among various subtypes at runtime.=
> This =3D> >in turn means it can't > > dispatch.> > >> > > So, just use pla=
>in procedure=3D> >s, an interface and a module, and you > > will get> > > e=
>verything a lighte=3D> >r-weight C++ class would give you.> > >> > >> > > >=
>> > > > Anyway, I've got=3D> >ten to accept C a bit more vs. C++ so I can >=
> > deal with> > > > t: Type;> =3D> >> > > Type_DoSomething(t);> > > >> > > =
>> in place of:> > > > t.DoSomething(=3D> >);> > >> > >> > > Exactly. The sp=
>ecial "receiver object" in a true method c=3D> >all has > > significant> > =
>> semantic differences from an ordinary paramete=3D> >r and introduces > > =
>new complexities> > > and non-orthogonalities. It has =3D> >some very valua=
>ble uses too.> > >> > > But to then create degenerate forms =3D> >of it tha=
>t still carry a lot > > of these> > > complexities, but are equiva=3D> >len=
>t in programing power to plain old> > > parameters is just bad program d=3D=
>> >esign and bad language design. > > Objects and> > > methods are indeed c=
>ool=3D> > for situations that utilize their > > semantic complexity.> > > B=
>ut it's d=3D> >eeply uncool to try to look superficially cool by using an> =
>> > inappropria=3D> >tely sophisticated construct when the problem doesn't =
>> > justify it.> > > =3D> >Some OO proponents have gone way over the deep e=
>nd here.> > >> > > >> > > >=3D> > - Jay> > > >> > > >> > > > > > ----------=
>---------------------------------=3D> >--------------------------- > > --> =
>> > > Boo! Scare away worms, viruses an=3D> >d so much more! Try Windows > =
>> Live OneCare! Try now!> > > <http://onecare=3D> >.live.com/standard/en-us=
>/purchase/trial.aspx? > > s_cid=3D3Dwl_hotmailnews>> =3D> >> >> > >> > > --=
>> > > -----------------------------------------------------=3D> >--------> =
>> > Rodney M. Bates, retired assistant professor> > > Dept. of Co=3D> >mput=
>er Science, Wichita State University> > > Wichita, KS 67260-0083> > > 3=3D>=
> >16-978-3922> > > rodney.bates at wichita.edu> > >> > > --> > > -------------=
>--=3D> >----------------------------------------------> > > Rodney M. Bates=
>, retire=3D> >d assistant professor> > > Dept. of Computer Science, Wichita=
> State Univers=3D> >ity> > > Wichita, KS 67260-0083> > > 316-978-3922> > > =
>rodney.bates at wichita=3D> >.edu> >> >> > Boo! Scare away worms, viruses and =
>so much more! Try Windows =3D> >Live > > OneCare! Try now!>=3D20> >________=
>_________________________________________________________> >Climb to the to=
>p of the charts!=3DA0 Play Star Shuffle:=3DA0 the word scramble =3D> >chall=
>enge with star power.> >http://club.live.com/star_shuffle.aspx?icid=3D3Dsta=
>rshuffle_wlmailtextlink_oc=3D> >t=3D> >> >--_0109391c-2ffe-4cfe-9165-c2a246=
>28c3c7_> >Content-Type: text/html; charset=3D"iso-8859-1"> >Content-Transfe=
>r-Encoding: quoted-printable> >> ><html>> ><head>> ><style>> >.hmmessage P>=
> >{> >margin:0px;> >padding:0px> >}> >body.hmmessage> >{> >FONT-SIZE: 10pt;=
>> >FONT-FAMILY:Tahoma> >}> ></style>> ></head>> ><body class=3D3D'hmmessage=
>'>But if I don't want to pay for heap allocation, I=3D> > can't say:<BR>> >=
> <BR>> >VAR T: v;<BR>> > <BR>> >v.DoSomething();<BR>> > <BR>=
>> >Only IMPORT T FROM M;<BR>> > <BR>> >VAR T: v;<BR>> > <BR>> >M.=
>DoSomething(v);<BR>> > <BR>> >Right?<BR><BR>> >SPIN I think you mean.<=
>BR>> >Anyone build it and bring it up? I was long curious but never did..<B=
>R>> > <BR>> > - Jay<BR><BR><BR>> >> ><HR id=3D3DstopSpelling>> ><=
>BR>> >> CC: m3devel at elegosoft.com<BR>> From: darko at darko.org<BR>> =
>Subjec=3D> >t: Re: [M3devel] small array in modula-3?<BR>> Date: Thu, 15=
> Nov 2007 20=3D> >:29:06 -0800<BR>> To: jay.krell at cornell.edu<BR>> <B=
>R>> Not sure wh=3D> >at the problem is with modules. If you want to avoi=
>d the <BR>> dot you c=3D> >an name the type something unique then import=
> that type <BR>> name. You =3D> >can create an interface with all the ni=
>ce type names and <BR>> import al=3D> >l those names in modules by addin=
>g an EXPORTS clause too.<BR>> <BR>> =3D> >Personally I think M3, with=
> a couple of extensions, wouldn't need <BR>> =3D> >unsafe anything. The =
>unsafe features are there mostly because of <BR>> l=3D> >egacy interface=
>s. I forget the name but the folk who wrote an OS in <BR>>=3D> >; M3 foun=
>d it very effective with only couple of minor points with <BR>>=3D> > re=
>gards to interfacing to C code they built on top of, I think one of <BR>=3D=
>> >> them was being able to pass NIL to a VAR parameter, which is a comm=
>on =3D> ><BR>> C idiom (and an annoying one for M3 users who then can't =
>use VAR).=3D> ><BR>> <BR>> <BR>> On 15/11/2007, at 8:08 PM, Jay wr=
>ote:<BR>> <B=3D> >R>> > Rodney, thank you, this is interesting.<BR=
>>> > I definite=3D> >ly don't want to pay for heap allocation for a t=
>iny array.<BR>> > I d=3D> >on't know about "subarray". It looks like =
>it takes and returns <BR>> >=3D> >; arrays. It's not a type. I ordered=
> another copy of the Nelson book <BR>&g=3D> >t; > so I don't have to fin=
>d mine.<BR>> ><BR>> > Good idea "=3D> >MakeT" I forgot about th=
>at pattern. I'll try it out.<BR>> ><BR>> &=3D> >gt; The record and=
> array I propose are not all that different really.<BR>&g=3D> >t; > I ju=
>st heard of something new. Have you heard of it? "Duck typing".=3D> > <BR>&=
>gt; > If it acts/quacks/walks like a duck, it is a duck.<BR>> &=3D> >=
>gt; This is in very dynamic languages like Ruby.<BR>> > You apply obj=
>=3D> >ect.method and if object defines something named <BR>> > "metho=
>d", th=3D> >en it "must" have "the" meaning you intend.<BR>> > Kind o=
>f like how C=3D> >++ templates "accept as parameters whatever <BR>> >=
> happens to work".=3D> ><BR>> ><BR>> > Operator overloading is =
>great for strings and "m=3D> >ath".<BR>> ><BR>> > Maybe I shoul=
>d try to have this language de=3D> >bate from scratch again..?<BR>> >=
><BR>> > I still am conflcted.<=3D> >BR>> ><BR>> > Modules=
> seem overly heavyweight.<BR>> > I d=3D> >on't want Module1.T, Module=
>2.T, I want T1, T2.<BR>> ><BR>> > C+=3D> >+ stack structs with =
>non virtual member functions:<BR>> > class Rect_=3D> >t<BR>> > =
>{<BR>> > Rect_t() : top(0), left(0), right(0), bottom(=3D> >0) { }<BR=
>>> ><BR>> > int Height() { return bottom - top; }<BR>&=3D> >gt;=
> > int Width() { return right - left; }<BR>> > int top, left, b=3D=
>> >ottom, right;<BR>> > };<BR>> ><BR>> > seems "good".<BR=
>>&g=3D> >t; ><BR>> > And it seems not really all that complicated =
>for the c=3D> >ompiler to <BR>> > flow the static type information ar=
>ound to resolve=3D> > the functions..<BR>> ><BR>> > Rect_t r;<B=
>R>> > r.Height(=3D> >) =3D3D> Rect_Height(&r); ..and would be =
>inlined anyway.<BR>> ><=3D> >BR>> > I do find some compelling f=
>eatures in Modula-3. Mainly that it=3D> > <BR>> > compiles to native =
>code and has OPTIONAL safety, optional ga=3D> >rbage <BR>> > collecti=
>on, and that the syntax of modules/interfaces a=3D> >llows fast <BR>> &g=
>t; compilation -- no longer reparsing the same header=3D> >s over and over =
><BR>> > and over and over.<BR>> ><BR>> > =3D> >Operator o=
>verloading btw..have seen "template SafeInt"? It acts <BR>> &g=3D> >t; l=
>ike a primitive integer, but raises exceptions upon overflow.<BR>> &=3D>=
> >gt; For this to work very much requires operator overloading.<BR>> >=
>;<=3D> >BR>> > A point, of course, is to be able to have user defined=
> types t=3D> >hat <BR>> > can act like the built in types..<BR>> &=
>gt;<BR>> &g=3D> >t; - Jay<BR>> ><BR>> ><BR>> > > Da=
>te: Thu, 15 Nov 2007=3D> > 18:39:18 -0600<BR>> > > From: rodney.ba=
>tes at wichita.edu<BR>> &g=3D> >t; > To: m3devel at elegosoft.com<BR>> &=
>gt; > Subject: Re: [M3devel] =3D> >small array in modula-3?<BR>> >=
> ><BR>> > > Jay wrote:<BR>=3D> >> > ><BR>> > >=
>; > What is the right way to have a varia=3D> >bly sized but always smal=
>l <BR>> > array in Modula-3?<BR>> > &g=3D> >t; > My array wi=
>ll only ever have 1 or 2 elements.<BR>> > > >=3D> >; I'd like to=
> always allocate room for 2 elements, and have there <BR>> =3D> >> be=
> a size.<BR>> > > ><BR>> > > > It seems I ha=3D> >v=
>e a choice of<BR>> > > ><BR>> > > > a) an "open" a=
>=3D> >rray<BR>> > ><BR>> > > Heap allocated, I presume? I=
>f the =3D> >max size is only 2 elements,<BR>> > > this is pretty e=
>xtravagant, =3D> >as a heap allocated open array will<BR>> > > hav=
>e 4 extra behind-t=3D> >he-scenes words of space overhead, plus<BR>> >=
>; > maybe heap fragme=3D> >ntation, and time overhead of allocation,<BR>=
>> > > collection, and=3D> > maybe reduced locality of reference.<B=
>R>> > ><BR>> > > &=3D> >gt; b) wrap it up in a record<BR>=
>> > > ><BR>> > > >=3D> > I'd like so have, like:<BR=
>>> > > ><BR>> > > > TYPE=3D> > A =3D3D ARRAY [0..1]=
> OF FOO;<BR>> > > ><BR>> > > > A=3D> >nd be able to=
> say:<BR>> > > ><BR>> > > > VAR<BR>>=3D> >; > =
>> > a : A;<BR>> > > ><BR>> > > > ..<BR=3D> >>=
>> > > > a.size<BR>> > > > FOR i :=3D3D 0 TO a.size =
>D=3D> >O<BR>> > > > do something with a[i]<BR>> > > &g=
>t;<BR>&=3D> >gt; > > > It seems I have no option but, like:<BR>>=
>; > > &=3D> >gt;<BR>> > > > TYPE A =3D3D RECORD<BR>> &=
>gt; > > a: ARRA=3D> >Y[0..1] OF FOO;<BR>> > > > size :=3D=
>3D 1; (* usually of size 1, s=3D> >ometimes 2 *)<BR>> > > > END=
><BR>> > > ><BR>> >=3D> >; > > and then<BR>> > =
>> > FOR i :=3D3D 0 TO a.size DO<BR>&g=3D> >t; > > > do somet=
>hing with a.a[i];<BR>> > > ><BR>> =3D> >> > > That =
>is "ok". Not great -- what to call the inner a?<BR>>=3D> > > > >=
>; But then furthermore, I'd like to construct constants.<BR>&=3D> >gt; >=
> > > It seems I am stuck with either the verbose:<BR>> >=3D> >; =
>> ><BR>> > > > PROCEDURE F(a:A);<BR>> > > >=
>=3D> ><BR>> > > > F( A { ARRAY[0..1] OF FOO { .. } );<BR>> &=
>gt; &g=3D> >t; ><BR>> > > > OR I have to come up with a name=
> for the emb=3D> >edded array.<BR>> > > > But of course, its ty=
>pe is really "the =3D> >same" as the outer type.<BR>> > ><BR>> =
>> ><BR>> > &=3D> >gt; Ignoring the fact that the types are diff=
>erent linguistically<BR>> &=3D> >gt; > (one a record type, the other =
>an array), the types are different<B=3D> >R>> > > at a deep semant=
>ic level too. The inner array has static<B=3D> >R>> > > size, the =
>outer one (call it a "variable array", perhaps)<=3D> >BR>> > > has=
> dynamically changeable size, even more easily changed=3D> ><BR>> > &=
>gt; after it is created than a heap-allocated open array. Th=3D> >is<BR>>=
>; > > is a significant semantic difference, so it also makes=3D> > pr=
>ogram<BR>> > > design sense to view them as different types.<BR=3D=
>> >>> > ><BR>> > > ><BR>> > > > To wit:<BR=
>>&g=3D> >t; > > ><BR>> > > > TYPE FooArray =3D3D ARRAY=
>[0..1] OF F=3D> >oo;<BR>> > > ><BR>> > > > TYPE Foo=
>Array =3D3D RECORD<=3D> >BR>> > > > a : FooArray;<BR>> > =
>> > size :=3D3D 1;<BR=3D> >>> > > > END;<BR>> > >=
>; ><BR>> > > > F( =3D> >FooArray { FooArray { .. } );<BR>>=
>; > > ><BR>> > > >=3D> > But I have to come up with di=
>fferent names.<BR>> > > ><BR>>=3D> > > > > And I do=
>n't think I can leave out the name for the construc=3D> >tor, <BR>> >=
> like:<BR>> > > ><BR>> > > > F( F=3D> >ooArray { { =
>.. } );<BR>> > ><BR>> > ><BR>> > > Y=3D> >es, th=
>is is a limitation in Modula-3. Ada allows value constructors<BR>>=3D> >=
> > > to omit inner type names in cases like this, and it is <BR>> =
>=3D> >> convenient. But<BR>> > > it also crosses a really major=
> line =3D> >on complexity of the language <BR>> > semantics,<BR>> =
>> > si=3D> >nce type analysis information now flows not only upward, =
>but <BR>> > =3D> >also downward<BR>> > > in expression typin=
>g. I am mostly content t=3D> >o live with this as <BR>> > one bit of<=
>BR>> > > the price of=3D> > avoiding a horribly over complex langu=
>age.<BR>> > ><BR>> > =3D> >> Ordinary procedures can do p=
>retty much all of the things done by <BR>&=3D> >gt; > exotic<BR>> >=
>; > and complex language stuff like C++ const=3D> >ructors. If you don't=
> <BR>> > want to write<BR>> > > the pon=3D> >derous nested v=
>alue constructor, write a constructor <BR>> > procedur=3D> >e and<BR>=
>> > > call it. As Antony suggested, you can make it accep=3D> >t a=
>n open <BR>> > array formal,<BR>> > > which then codes ju=3D=
>> >st like a simple array value constructor. You <BR>> > could even<B=
>R>&=3D> >gt; > > make it elaborate and general, e.g.:<BR>> > &g=
>t;<BR>>=3D> >; > > PROCEDURE MakeF ( Val : ARRAY OF FOO ) : F<BR>&g=
>t; > ><BR=3D> >>> > > =3D3D VAR LSize : CARDINAL<BR>> >=
>; > ; VAR LResult : =3D> >A<BR>> > ><BR>> > > ; BEGIN<=
>BR>> > > LSize :=3D3D =3D> >NUMBER ( Val )<BR>> > > <*=
> ASSERT LSize <=3D3D NUMBER ( FooArr=3D> >ay ) *><BR>> > > ;=
> LResult . size :=3D3D LSize<BR>> > > =3D> >; SUBARRAY ( LResult .=
> a , 0 , LSize )<BR>> > > :=3D3D SUBARRAY ( Va=3D> >l , FIRST ( Va=
>l ) , LSize )<BR>> > > ; RETURN LResult<BR>> >=3D> > > EN=
>D MakeF<BR>> > ><BR>> > > Alternatively, since yo=3D> >ur=
> maximum element count is so small, you <BR>> > could<BR>> > =
>=3D> >> write a constructor procedure that took two formals of type FOO,=
> <BR>&=3D> >gt; > with<BR>> > > at least the second one optiona=
>l. (This wou=3D> >ld require a <BR>> > distinguished<BR>> > >=
>; value of type FO=3D> >O that would be used to mean "omitted".)<BR>> &g=
>t; ><BR>> > >=3D> >; And, of course, if you want to use abstract=
>ion, you can put the <BR>> =3D> >> types,<BR>> > > construct=
>or procedures, and various other pro=3D> >cedures for <BR>> > manipul=
>ating<BR>> > > the variable sized=3D> > array in a module, behind =
>an interface.<BR>> > ><BR>> > >=3D> >; An additional limit=
>ation of Modula-3 in this regard, is that you <BR>>=3D> > > can't<BR>=
>> > > make the type F opaque, unless you heap alloc=3D> >ate it, w=
>hich we <BR>> > were trying<BR>> > > to avoid. Ada =3D> >wou=
>ld allow you to do this, but it's another <BR>> > example of<BR>&g=3D=
>> >t; > > a convenience with high cost. It forces the equivalent of t=
>he =3D> ><BR>> > revelation<BR>> > > to be located in the eq=
>uivalent =3D> >of the interface, but makes it <BR>> > illegal<BR>>=
> > > to w=3D> >rite client code that depends on what the revelation i=
>s.<BR>> > ><=3D> >BR>> > > This in turn creates a source =
>code control nightmare in a=3D> > large <BR>> > project,<BR>> >=
> > because now someone who wan=3D> >ts to make what is really a purely <=
>BR>> > internal,<BR>> > >=3D> >; implementation change, never=
>theless has to check out the <BR>> > in=3D> >terface, and<BR>> >=
>; > if you aren't in denial mode, that means imp=3D> >lementers of all t=
>he <BR>> > client<BR>> > > code have to go=3D> > to extra tr=
>ouble to somehow find out that what <BR>> > appears<BR>&g=3D> >t; >=
>; > to be an interface change actually doesn't affect them after a=3D> >=
>ll.<BR>> > ><BR>> > > ><BR>> > > > Though =
>=3D> >that might seem nice.<BR>> > > ><BR>> > > > A=
>m I un=3D> >derstanding everything?<BR>> > > ><BR>> > >=
>; > Have =3D> >folks hit this before and there's a set of names that <BR=
>>> > don't s=3D> >eem too lame<BR>> > > > that folks use?=
><BR>> > > ><=3D> >BR>> > > > Also -- language docum=
>entation?<BR>> > > &g=3D> >t; Nelson's green book is excellent.<BR=
>>> > > > The stuff in th=3D> >e doc directory is very dry and s=
>cientific.<BR>> > > > The tuto=3D> >rial seems more like a refe=
>rence. Or maybe I didn't <BR>> > read it e=3D> >nough.<BR>> > &=
>gt; > Is there better, in case I need a refresher?<=3D> >BR>> > &g=
>t; > I think I got it, via Nelson's book from memory (won=3D> >der if I =
><BR>> > can find mine..) and the reference,<BR>> > >=3D> >; &=
>gt; but I don't think anyone could learn from the current online <BR>>=3D=
>> >; > docs in the source tree.<BR>> > > ><BR>> > >=
> &g=3D> >t; Maybe it's me, some combination of laziness and short attention=
> <BR>>=3D> > > span<BR>> > > > as I age..<BR>> > &g=
>t; ><BR>>=3D> > > > > Btw, C doesn't offer a great solution =
>here, though it offer=3D> >s <BR>> > leaving out some type names.<BR>=
>> > > > In C++ =3D> >I could have both .size and operator[].<BR=
>>> > > > Modula-3 see=3D> >ms to be missing operator overloadin=
>g.<BR>> > > > It's got some=3D> > builtin stuff, even array ass=
>ignment and equality <BR>> > and I thin=3D> >k<BR>> > > >=
> even record assignment and equality, but it is sti=3D> >ll a bit <BR>> =
>> limiting.<BR>> > ><BR>> > ><BR>>=3D> >; > > =
>I have raved on this before, but, having had lots of painful <B=3D> >R>>=
> > experience with<BR>> > > user-defined overloading in A=3D> >=
>da and C++, I can say with <BR>> > authority, that it is<BR>> >=
>=3D> > > a programming language disaster. It interacts with just about <=
>BR>>=3D> >; > everything<BR>> > > else in the language, in ve=
>ry complicat=3D> >ed ways, and all it buys <BR>> > you is saving<BR>&=
>gt; > > time=3D> >/energy thinking up distinct names for procedures/f=
>unctions. <BR>> > =3D> >Even this,<BR>> > > aside from the e=
>ffects on the language, is a n=3D> >et loss, by the <BR>> > time you =
>consider<BR>> > > readabili=3D> >ty along with writability.<BR>>=
>; > ><BR>> > > User-defined=3D> > overloaded operators provi=
>de a slight readability <BR>> > benefit, _=3D> >if_<BR>> > >=
> used with great restraint and discipline, something y=3D> >ou can rely <BR=
>>> > on not happening.<BR>> > > Meanwhile, th=3D> >e languag=
>e complexity can easily double or worse. <BR>> > And, with t=3D> >he<=
>BR>> > > exception of compiler writers and language lawyers who=3D=
>> > spend <BR>> > hundreds of hours<BR>> > > on just this, p=
>rog=3D> >rammers don't understand the rules, not even <BR>> > close.<=
>BR>> &=3D> >gt; ><BR>> > > ><BR>> > > > Also,=
> if I understan=3D> >d things correctly, this has long bothered <BR>> &g=
>t; me about Modula-3,=3D> ><BR>> > > > though I'm more tolerant=
> now -- Modula-3 doesn't se=3D> >em to allow <BR>> > for lighter wieg=
>ht<BR>> > > > objects=3D> >. Like, small stack allocated struct=
>s with member <BR>> > functions. =3D> >You seem to have<BR>> > =
>> > to chose between heap allocated gar=3D> >bage collected virtual <=
>BR>> > member functions full<BR>> > >=3D> >; > featured ob=
>jects, or featureless dumb structs. It's nice how C+ <BR>=3D> >> > + =
>allow hybrids --<BR>> > > > objects don't have to b=3D> >e heap=
> allocated and member functions <BR>> > don't have be virtual.<=3D> >=
>BR>> > > > Or am I missing something?<BR>> > ><BR>>=
>=3D> > > ><BR>> > > C++'s supposedly lighter weight forms of=
> class=3D> >es/structs with <BR>> > their special<BR>> > > m=
>ember functi=3D> >ons buy nothing that plain records, plain <BR>> > p=
>rocedures, and<BR>=3D> >> > > interfaces/modules don't already pro=
>vide, again, at signific=3D> >ant <BR>> > and gratuitous<BR>> >=
> > language complexity. Exc=3D> >ept when methods/member functions <BR>&=
>gt; > actually dispatch<BR>> &=3D> >gt; > dynamically, there is no=
>thing that the above won't do, and when <B=3D> >R>> > you create a<BR=
>>> > > class instance as a local variab=3D> >le (i.e., on the stac=
>k), it is <BR>> > necessarily<BR>> > > =3D> >not polymorphic=
>, that is, it can't change its "allocated" or <BR>> > =3D> >dynamic t=
>ype<BR>> > > among various subtypes at runtime. This in t=3D> >urn=
> means it can't <BR>> > dispatch.<BR>> > ><BR>> > &=3D=
>> >gt; So, just use plain procedures, an interface and a module, and you <B=
>R>&=3D> >gt; > will get<BR>> > > everything a lighter-weight C+=
>+ class w=3D> >ould give you.<BR>> > ><BR>> > ><BR>> &=
>gt; > ><B=3D> >R>> > > > Anyway, I've gotten to accept C =
>a bit more vs. C++ so=3D> > I can <BR>> > deal with<BR>> > >=
> > t: Type;<BR>> >=3D> > > > Type_DoSomething(t);<BR>> &g=
>t; > ><BR>> > > &g=3D> >t; in place of:<BR>> > > &g=
>t; t.DoSomething();<BR>> > ><B=3D> >R>> > ><BR>> > =
>> Exactly. The special "receiver object" i=3D> >n a true method call has=
> <BR>> > significant<BR>> > > semant=3D> >ic differences fro=
>m an ordinary parameter and introduces <BR>> > new =3D> >complexities=
><BR>> > > and non-orthogonalities. It has some very va=3D> >luable=
> uses too.<BR>> > ><BR>> > > But to then create deg=3D> >=
>enerate forms of it that still carry a lot <BR>> > of these<BR>> &=
>=3D> >gt; > complexities, but are equivalent in programing power to plai=
>n old<=3D> >BR>> > > parameters is just bad program design and bad=
> language de=3D> sign. <BR>> > Objects and<BR>> > > methods =
>are indeed cool f=3D> >or situations that utilize their <BR>> > seman=
>tic complexity.<BR>>=3D> > > > But it's deeply uncool to try to lo=
>ok superficially cool by usin=3D> >g an<BR>> > > inappropriately s=
>ophisticated construct when the pro=3D> >blem doesn't <BR>> > justify=
> it.<BR>> > > Some OO proponents=3D> > have gone way over the deep=
> end here.<BR>> > ><BR>> > > =3D> >><BR>> > >=
> > - Jay<BR>> > > ><BR>> > > =3D> >><BR>> >=
>; > > <BR>> > ---------------------------------=3D> >----------=
>--------------------------- <BR>> > --<BR>> > > &g=3D> >t; B=
>oo! Scare away worms, viruses and so much more! Try Windows <BR>> &g=3D>=
> >t; Live OneCare! Try now!<BR>> > > <http://onecare.live.com/s=
>ta=3D> >ndard/en-us/purchase/trial.aspx? <BR>> > s_cid=3D3Dwl_hotmail=
>news><B=3D> >R>> > ><BR>> > ><BR>> > > --<BR>=
>> > > -=3D> >-----------------------------------------------------=
>-------<BR>> > &=3D> >gt; Rodney M. Bates, retired assistant professo=
>r<BR>> > > Dept. of=3D> > Computer Science, Wichita State Universi=
>ty<BR>> > > Wichita, KS 6=3D> >7260-0083<BR>> > > 316-978=
>-3922<BR>> > > rodney.bates at wic=3D> >hita.edu<BR>> > ><BR=
>>> > > --<BR>> > > ---------=3D> >-----------------------=
>-----------------------------<BR>> > > Rodn=3D> >ey M. Bates, reti=
>red assistant professor<BR>> > > Dept. of Compute=3D> >r Science, =
>Wichita State University<BR>> > > Wichita, KS 67260-008=3D> >3<BR>=
>> > > 316-978-3922<BR>> > > rodney.bates at wichita.edu=3D> =
>><BR>> ><BR>> ><BR>> > Boo! Scare away worms, viruses and=
=3D> >so much more! Try Windows Live <BR>> > OneCare! Try now!<BR>&g=
>t; <BR>=3D> ><BR><br /><hr />Climb to the top of the charts!=3DA0 Play Star=
> Shuffle:=3DA0 th=3D> >e word scramble challenge with star power. <a href=
>=3D3D'http://club.live.com/=3D> >star_shuffle.aspx?icid=3D3Dstarshuffle_wlm=
>ailtextlink_oct' target=3D3D'_new'>Pl=3D> >ay Now!</a></body>> ></html>=3D>=
> >> >--_0109391c-2ffe-4cfe-9165-c2a24628c3c7_--
>_________________________________________________________________
>Help yourself to FREE treats served up daily at the Messenger Caf=E9. Stop =
>by today.
>http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=3DTXT_TAGLM_Oc=
>tWLtagline=
>
>--_85b6c041-9539-4614-b541-8813489e58bb_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px;
>padding:0px
>}
>body.hmmessage
>{
>FONT-SIZE: 10pt;
>FONT-FAMILY:Tahoma
>}
></style>
></head>
><body class=3D'hmmessage'>> VAR v : T;<BR>> DoSomething(v);<BR>> <=
>BR>> What's the big deal if it's DoSomething(v) or <FONT face=3D"">v.<FO=
>NT face=3D"">DoSomething</FONT></FONT>()?<BR><BR> VAR x : T1;<BR>=
> VAR y : T2;<BR> DoSomething(x);<BR> DoSomething(y);<BR=
>><BR>
>isn't legal, right?<BR>
> <BR>
>So I have to:<BR>
><BR> M1.DoSomething(x);<BR> M2.DoSomething(y);<BR><BR>
>right? Constantly repeating types, or modules, on function names?<BR>
> <BR>
> - Jay<BR>
> <BR>
>
><HR id=3DstopSpelling>
><BR>
>> To: jay.krell at cornell.edu<BR>> Subject: Re: [M3devel] small array i=
>n modula-3? <BR>> Date: Thu, 15 Nov 2007 21:00:13 -0800<BR>> From: mi=
>ka at async.caltech.edu<BR>> <BR>> Why not <BR>> <BR>> FROM M IMPO=
>RT T, DoSomething;<BR>> <BR>> VAR v : T;<BR>> DoSomething(v);<BR>&=
>gt; <BR>> What's the big deal if it's DoSomething(v) or <FONT face=3D"">=
>v.<FONT face=3D"">DoSomething</FONT></FONT>()?<BR>> <BR>> If anything=
>, "DoSomething(v)" tells me that the call can be statically<BR>> resolve=
>d, whereas <FONT face=3D"">v.<FONT face=3D"">DoSomething</FONT></FONT>() te=
>lls me that something odd can<BR>> happen at runtime---that is, I cannot=
> be sure I understand this<BR>> code simply by looking for a routine cal=
>led "DoSomething" and reading<BR>> that, but have to be more careful. Th=
>is distinction is unclear in<BR>> C++. What, in fact, is the distinction=
> in C++ between DoSomething(v)<BR>> and <FONT face=3D"">v.<FONT face=3D"=
>">DoSomething</FONT></FONT>()? None, right? Just two ways of saying the<BR>=
>> same thing... why?<BR>> <BR>> The Modula-2+ work on the Firefly =
>is also close enough to be "almost"<BR>> Modula-3...<BR>> <BR>> Re=
>garding UNSAFE: most interfaces to C code are (or should be)<BR>> UNSAFE=
> because there are ways of calling them that can lead to<BR>> unchecked =
>runtime errors. I don't see how you can live without<BR>> UNSAFE if you =
>ever want to link with other people's C libraries...<BR>> <BR>> Mika<=
>BR>> <BR>> Jay writes:<BR>> >--_0109391c-2ffe-4cfe-9165-c2a2462=
>8c3c7_<BR>> >Content-Type: text/plain; charset=3D"iso-8859-1"<BR>>=
> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> >B=
>ut if I don't want to pay for heap allocation, I can't say:<BR>> >=3D=
>20<BR>> >VAR T: v;<BR>> >=3D20<BR>> ><FONT face=3D"">v.<F=
>ONT face=3D"">DoSomething</FONT></FONT>();<BR>> >=3D20<BR>> >On=
>ly IMPORT T FROM M;<BR>> >=3D20<BR>> >VAR T: v;<BR>> >=3D=
>20<BR>> >M.DoSomething(v);<BR>> >=3D20<BR>> >Right?<BR>&g=
>t; >SPIN I think you mean.<BR>> >Anyone build it and bring it up? =
>I was long curious but never did..<BR>> >=3D20<BR>> > - Jay<BR>=
>> ><BR>> ><BR>> ><BR>> >> CC: m3devel at elegosoft.=
>com> From: darko at darko.org> Subject: Re: [M3devel] =3D<BR>> >sm=
>all array in modula-3?> Date: Thu, 15 Nov 2007 20:29:06 -0800> To: ja=
>y.kr=3D<BR>> >ell at cornell.edu> > Not sure what the problem is w=
>ith modules. If you want t=3D<BR>> >o avoid the > dot you can name=
> the type something unique then import that t=3D<BR>> >ype > name.=
> You can create an interface with all the nice type names and > =3D<BR>&=
>gt; >import all those names in modules by adding an EXPORTS clause too.&=
>gt; > Perso=3D<BR>> >nally I think M3, with a couple of extensions=
>, wouldn't need > unsafe anyth=3D<BR>> >ing. The unsafe features a=
>re there mostly because of > legacy interfaces. I=3D<BR>> > forget=
> the name but the folk who wrote an OS in > M3 found it very effecti=3D<=
>BR>> >ve with only couple of minor points with > regards to interf=
>acing to C code=3D<BR>> > they built on top of, I think one of > t=
>hem was being able to pass NIL to =3D<BR>> >a VAR parameter, which is=
> a common > C idiom (and an annoying one for M3 us=3D<BR>> >ers wh=
>o then can't use VAR).> > > On 15/11/2007, at 8:08 PM, Jay wrote:&=
>gt; > =3D<BR>> >> Rodney, thank you, this is interesting.> &=
>gt; I definitely don't want to pay=3D<BR>> > for heap allocation for =
>a tiny array.> > I don't know about "subarray". It=3D<BR>> > lo=
>oks like it takes and returns > > arrays. It's not a type. I ordered =
>ano=3D<BR>> >ther copy of the Nelson book > > so I don't have t=
>o find mine.> >> > Good i=3D<BR>> >dea "MakeT" I forgot a=
>bout that pattern. I'll try it out.> >> > The record =3D<BR>>=
>; >and array I propose are not all that different really.> > I jus=
>t heard of s=3D<BR>> >omething new. Have you heard of it? "Duck typin=
>g". > > If it acts/quacks/wa=3D<BR>> >lks like a duck, it is a =
>duck.> > This is in very dynamic languages like Ru=3D<BR>> >by.=
>> > You apply object.method and if object defines something named >=
>; > "m=3D<BR>> >ethod", then it "must" have "the" meaning you inte=
>nd.> > Kind of like how C=3D<BR>> >++ templates "accept as para=
>meters whatever > > happens to work".> >> > Ope=3D<BR>>=
>; >rator overloading is great for strings and "math".> >> > =
>Maybe I should try=3D<BR>> > to have this language debate from scratc=
>h again..?> >> > I still am conflc=3D<BR>> >ted.> >=
>> > Modules seem overly heavyweight.> > I don't want Module1.T,=
> Modu=3D<BR>> >le2.T, I want T1, T2.> >> > C++ stack stru=
>cts with non virtual member funct=3D<BR>> >ions:> > class Rect_=
>t> > {> > Rect_t() : top(0), left(0), right(0), bottom(=3D<BR>&=
>gt; >0) { }> >> > int Height() { return bottom - top; }> =
>> int Width() { return =3D<BR>> >right - left; }> > int top,=
> left, bottom, right;> > };> >> > seems "good".>=3D<BR=
>>> > >> > And it seems not really all that complicated for t=
>he compiler to > > =3D<BR>> >flow the static type information a=
>round to resolve the functions..> >> > Re=3D<BR>> >ct_t r=
>;> > r.Height() =3D3D> Rect_Height(&r); ..and would be inlined=
> anyway.>=3D<BR>> > >> > I do find some compelling featur=
>es in Modula-3. Mainly that it > > co=3D<BR>> >mpiles to native=
> code and has OPTIONAL safety, optional garbage > > collect=3D<BR>>=
>; >ion, and that the syntax of modules/interfaces allows fast > > =
>compilation =3D<BR>> >-- no longer reparsing the same headers over an=
>d over > > and over and over=3D<BR>> >.> >> > Opera=
>tor overloading btw..have seen "template SafeInt"? It acts > >=3D<BR>=
>> > like a primitive integer, but raises exceptions upon overflow.>=
>; > For this=3D<BR>> > to work very much requires operator overloa=
>ding.> >> > A point, of course,=3D<BR>> > is to be able t=
>o have user defined types that > > can act like the built i=3D<BR>>=
>; >n types..> >> > - Jay> >> >> > > Dat=
>e: Thu, 15 Nov 2007 18:39:18 -0600> > >=3D<BR>> > From: rodn=
>ey.bates at wichita.edu> > > To: m3devel at elegosoft.com> > > =
>Subject=3D<BR>> >: Re: [M3devel] small array in modula-3?> > &g=
>t;> > > Jay wrote:> > >> > > > W=3D<BR>> &=
>gt;hat is the right way to have a variably sized but always small > >=
> array in=3D<BR>> > Modula-3?> > > > My array will only e=
>ver have 1 or 2 elements.> > > > I'd =3D<BR>> >like to al=
>ways allocate room for 2 elements, and have there > > be a size.>=
>=3D<BR>> > > > >> > > > It seems I have a choice=
> of> > > >> > > > a) an "open" array>=3D<BR>>=
> > > >> > > Heap allocated, I presume? If the max size is=
> only 2 elements,> >=3D<BR>> > > this is pretty extravagant,=
> as a heap allocated open array will> > > hav=3D<BR>> >e 4 e=
>xtra behind-the-scenes words of space overhead, plus> > > maybe he=
>ap f=3D<BR>> >ragmentation, and time overhead of allocation,> >=
> > collection, and maybe r=3D<BR>> >educed locality of reference.&=
>gt; > >> > > > b) wrap it up in a record> > > &g=
>t;>=3D<BR>> > > > > I'd like so have, like:> > >=
> >> > > > TYPE A =3D3D ARRAY [0..1] OF FOO=3D<BR>> >;&=
>gt; > > >> > > > And be able to say:> > > >=
>;> > > > VAR> > > > a : A;> > > >>=
>=3D<BR>> > > > > ..> > > > a.size> > > =
>> FOR i :=3D3D 0 TO a.size DO> > > > do somethin=3D<BR>> =
>>g with a[i]> > > >> > > > It seems I have no op=
>tion but, like:> > > >> > > =3D<BR>> >> TYPE =
>A =3D3D RECORD> > > > a: ARRAY[0..1] OF FOO;> > > >=
> size :=3D3D 1; (* us=3D<BR>> >ually of size 1, sometimes 2 *)> &g=
>t; > > END> > > >> > > > and then> > &g=
>t; > FO=3D<BR>> >R i :=3D3D 0 TO a.size DO> > > > do s=
>omething with a.a[i];> > > >> > > > That=3D<BR>>=
> > is "ok". Not great -- what to call the inner a?> > > > Bu=
>t then furthermor=3D<BR>> >e, I'd like to construct constants.> &g=
>t; > > It seems I am stuck with either =3D<BR>> >the verbose:&g=
>t; > > >> > > > PROCEDURE F(a:A);> > > >&g=
>t; > > > F( A { ARRAY[0..=3D<BR>> >1] OF FOO { .. } );> &=
>gt; > >> > > > OR I have to come up with a name for the =
>=3D<BR>> >embedded array.> > > > But of course, its type =
>is really "the same" as the =3D<BR>> >outer type.> > >> &=
>gt; >> > > Ignoring the fact that the types are different l=3D<=
>BR>> >inguistically> > > (one a record type, the other an ar=
>ray), the types are d=3D<BR>> >ifferent> > > at a deep seman=
>tic level too. The inner array has static> > >=3D<BR>> > siz=
>e, the outer one (call it a "variable array", perhaps)> > > has dy=
>namic=3D<BR>> >ally changeable size, even more easily changed> >=
>; > after it is created tha=3D<BR>> >n a heap-allocated open array=
>. This> > > is a significant semantic differen=3D<BR>> >ce, =
>so it also makes program> > > design sense to view them as differe=
>nt ty=3D<BR>> >pes.> > >> > > >> > > &g=
>t; To wit:> > > >> > > > TYPE FooArray =3D3D ARRAY[=
>0..1]=3D<BR>> > OF Foo;> > > >> > > > TYPE Fo=
>oArray =3D3D RECORD> > > > a : FooArray;> > > >=3D<=
>BR>> > size :=3D3D 1;> > > > END;> > > >> =
>> > > F( FooArray { FooArray { .. } );> >=3D<BR>> > &g=
>t; >> > > > But I have to come up with different names.> =
>> > >> > > > And I=3D<BR>> > don't think I can l=
>eave out the name for the constructor, > > like:> > > >=
>=3D<BR>> >> > > > F( FooArray { { .. } );> > >&g=
>t; > >> > > Yes, this is a limitation in=3D<BR>> > Mod=
>ula-3. Ada allows value constructors> > > to omit inner type names=
> in c=3D<BR>> >ases like this, and it is > > convenient. But>=
>; > > it also crosses a really=3D<BR>> > major line on complexi=
>ty of the language > > semantics,> > > since type an=3D<BR>&=
>gt; >alysis information now flows not only upward, but > > also do=
>wnward> > > in=3D<BR>> > expression typing. I am mostly cont=
>ent to live with this as > > one bit of=3D<BR>> >> > >=
> the price of avoiding a horribly over complex language.> > >> =
>> > Ord=3D<BR>> >inary procedures can do pretty much all of the=
> things done by > > exotic> >=3D<BR>> > > and complex =
>language stuff like C++ constructors. If you don't > > want =3D<BR>&g=
>t; >to write> > > the ponderous nested value constructor, write=
> a constructor >=3D<BR>> > > procedure and> > > call i=
>t. As Antony suggested, you can make it accept =3D<BR>> >an open >=
> array formal,> > > which then codes just like a simple array=
> va=3D<BR>> >lue constructor. You > > could even> > > =
>make it elaborate and general, e.g=3D<BR>> .:> > >> > >=
>; PROCEDURE MakeF ( Val : ARRAY OF FOO ) : F> > >> > > =
>=3D3D VAR L=3D<BR>> >Size : CARDINAL> > > ; VAR LResult : A&=
>gt; > >> > > ; BEGIN> > > LSize :=3D3D NU=3D<BR>>=
>; >MBER ( Val )> > > <* ASSERT LSize <=3D3D NUMBER ( FooA=
>rray ) *>> > > ; LResul=3D<BR>> >t . size :=3D3D LSize>=
>; > > ; SUBARRAY ( LResult . a , 0 , LSize )> > > :=3D3D S=
>=3D<BR>> >UBARRAY ( Val , FIRST ( Val ) , LSize )> > > ; RET=
>URN LResult> > > END Make=3D<BR>> >F> > >> > =
>> Alternatively, since your maximum element count is so small, yo=3D<BR>=
>> >u > > could> > > write a constructor procedure that=
> took two formals of typ=3D<BR>> >e FOO, > > with> > >=
> at least the second one optional. (This would require =3D<BR>> >a &g=
>t; > distinguished> > > value of type FOO that would be used to=
> mean "omit=3D<BR>> >ted".)> > >> > > And, of cours=
>e, if you want to use abstraction, you can pu=3D<BR>> >t the > >=
>; types,> > > constructor procedures, and various other procedures=
> =3D<BR>> >for > > manipulating> > > the variable size=
d array in a module, behind an i=3D<BR>> >nterface.> > >>=
> > > An additional limitation of Modula-3 in this regard, is=3D<BR>&g=
>t; > that you > > can't> > > make the type F opaque, unle=
>ss you heap allocate i=3D<BR>> >t, which we > > were trying>=
> > > to avoid. Ada would allow you to do this, =3D<BR>> >but it=
>'s another > > example of> > > a convenience with high cost.=
> It force=3D<BR>> >s the equivalent of the > > revelation> &=
>gt; > to be located in the equivalent=3D<BR>> > of the interface, =
>but makes it > > illegal> > > to write client code that =3D<=
>BR>> >depends on what the revelation is.> > >> > > =
>This in turn creates a source =3D<BR>> >code control nightmare in a l=
>arge > > project,> > > because now someone who=3D<BR>> &g=
>t; wants to make what is really a purely > > internal,> > > =
>implementation ch=3D<BR>> >ange, nevertheless has to check out the &g=
>t; > interface, and> > > if you aren=3D<BR>> >'t in denia=
>l mode, that means implementers of all the > > client> > > c=
>ode =3D<BR>> >have to go to extra trouble to somehow find out that wh=
>at > > appears> > > =3D<BR>> >to be an interface chang=
>e actually doesn't affect them after all.> > >> > >=3D<BR=
>>> > >> > > > Though that might seem nice.> > &g=
>t; >> > > > Am I understanding eve=3D<BR>> >rything?&g=
>t; > > >> > > > Have folks hit this before and there's=
> a set of name=3D<BR>> >s that > > don't seem too lame> >=
> > > that folks use?> > > >> > > > Also --=3D=
><BR>> > language documentation?> > > > Nelson's green boo=
>k is excellent.> > > > Th=3D<BR>> >e stuff in the doc dir=
>ectory is very dry and scientific.> > > > The tutoria=3D<BR>>=
>; >l seems more like a reference. Or maybe I didn't > > read it en=
>ough.> > > >=3D<BR>> > Is there better, in case I need a =
>refresher?> > > > I think I got it, via =3D<BR>> >Nelson'=
>s book from memory (wonder if I > > can find mine..) and the referen=
>=3D<BR>> >ce,> > > > but I don't think anyone could learn=
> from the current online > >=3D<BR>> > docs in the source tree.=
>> > > >> > > > Maybe it's me, some combination of =
>=3D<BR>> >laziness and short attention > > span> > > &=
>gt; as I age..> > > >> > > > Btw, =3D<BR>> >C=
> doesn't offer a great solution here, though it offers > > leaving ou=
>t som=3D<BR>> >e type names.> > > > In C++ I could have b=
>oth .size and operator[].> > > > =3D<BR>> >Modula-3 seems=
> to be missing operator overloading.> > > > It's got some bui=
>=3D<BR>> >ltin stuff, even array assignment and equality > > an=
>d I think> > > > even =3D<BR>> >record assignment and equ=
>ality, but it is still a bit > > limiting.> > >> >=3D<=
>BR>> > >> > > I have raved on this before, but, having ha=
>d lots of painful > > ex=3D<BR>> >perience with> > > u=
>ser-defined overloading in Ada and C++, I can say with =3D<BR>> >>=
> > authority, that it is> > > a programming language disaster. =
>It interact=3D<BR>> >s with just about > > everything> > =
>> else in the language, in very complic=3D<BR>> >ated ways, and al=
>l it buys > > you is saving> > > time/energy thinking up d=
>=3D<BR>> >istinct names for procedures/functions. > > Even this=
>,> > > aside from the =3D<BR>> >effects on the language, is =
>a net loss, by the > > time you consider> > > r=3D<BR>> &=
>gt;eadability along with writability.> > >> > > User-defi=
>ned overloaded operat=3D<BR>> >ors provide a slight readability > =
>> benefit, _if_> > > used with great res=3D<BR>> >traint =
>and discipline, something you can rely > > on not happening.> >=
> > Me=3D<BR>> >anwhile, the language complexity can easily double =
>or worse. > > And, with =3D<BR>> >the> > > exception o=
>f compiler writers and language lawyers who spend > > h=3D<BR>> &g=
>t;undreds of hours> > > on just this, programmers don't understand=
> the rules,=3D<BR>> > not even > > close.> > >> >=
>; > >> > > > Also, if I understand things correc=3D<BR>&g=
>t; >tly, this has long bothered > > me about Modula-3,> > &g=
>t; > though I'm more t=3D<BR>> >olerant now -- Modula-3 doesn't se=
>em to allow > > for lighter wieght> > > >=3D<BR>> >=
> objects. Like, small stack allocated structs with member > > functio=
>ns. Yo=3D<BR>> >u seem to have> > > > to chose between he=
>ap allocated garbage collected vir=3D<BR>> >tual > > member fun=
>ctions full> > > > featured objects, or featureless dumb=3D<BR>=
>> > structs. It's nice how C+ > > + allow hybrids --> > &=
>gt; > objects don't have=3D<BR>> > to be heap allocated and member=
> functions > > don't have be virtual.> > > =3D<BR>> >&=
>gt; Or am I missing something?> > >> > >> > > C+=
>+'s supposedly lighter weight=3D<BR>> > forms of classes/structs with=
> > > their special> > > member functions buy =3D<BR>> >=
>;nothing that plain records, plain > > procedures, and> > > =
>interfaces/modul=3D<BR>> >es don't already provide, again, at signifi=
>cant > > and gratuitous> > > lan=3D<BR>> >guage comple=
>xity. Except when methods/member functions > > actually dispatc=3D<BR=
>>> >h> > > dynamically, there is nothing that the above won'=
>t do, and when > > =3D<BR>> >you create a> > > class i=
>nstance as a local variable (i.e., on the stack), =3D<BR>> >it is >=
>; > necessarily> > > not polymorphic, that is, it can't change =
>its "a=3D<BR>> >llocated" or > > dynamic type> > > amo=
>ng various subtypes at runtime. This =3D<BR>> >in turn means it can't=
> > > dispatch.> > >> > > So, just use plain procedu=
>re=3D<BR>> >s, an interface and a module, and you > > will get&=
>gt; > > everything a lighte=3D<BR>> >r-weight C++ class would g=
>ive you.> > >> > >> > > >> > > > =
>Anyway, I've got=3D<BR>> >ten to accept C a bit more vs. C++ so I can=
> > > deal with> > > > t: Type;> =3D<BR>> >> &=
>gt; > Type_DoSomething(t);> > > >> > > > in plac=
>e of:> > > > t.DoSomething(=3D<BR>> >);> > >>=
> > >> > > Exactly. The special "receiver object" in a true m=
>ethod c=3D<BR>> >all has > > significant> > > semantic=
> differences from an ordinary paramete=3D<BR>> >r and introduces >=
> > new complexities> > > and non-orthogonalities. It has =3D<BR=
>>> >some very valuable uses too.> > >> > > But to t=
>hen create degenerate forms =3D<BR>> >of it that still carry a lot &g=
>t; > of these> > > complexities, but are equiva=3D<BR>> >=
>lent in programing power to plain old> > > parameters is just bad =
>program d=3D<BR>> >esign and bad language design. > > Objects a=
>nd> > > methods are indeed cool=3D<BR>> > for situations tha=
>t utilize their > > semantic complexity.> > > But it's d=3D<=
>BR>> >eeply uncool to try to look superficially cool by using an> =
>> > inappropria=3D<BR>> >tely sophisticated construct when the =
>problem doesn't > > justify it.> > > =3D<BR>> >Some OO=
> proponents have gone way over the deep end here.> > >> > &g=
>t; >> > > >=3D<BR>> > - Jay> > > >> >=
>; > >> > > > > > ----------------------------------=
>---------=3D<BR>> >--------------------------- > > --> > =
>> > Boo! Scare away worms, viruses an=3D<BR>> >d so much more! =
>Try Windows > > Live OneCare! Try now!> > > <http://oneca=
>re=3D<BR>> >.live.com/standard/en-us/purchase/trial.aspx? > > s=
>_cid=3D3Dwl_hotmailnews>> =3D<BR>> >> >> > >>=
> > > --> > > -----------------------------------------------=
>------=3D<BR>> >--------> > > Rodney M. Bates, retired assis=
>tant professor> > > Dept. of Co=3D<BR>> >mputer Science, Wic=
>hita State University> > > Wichita, KS 67260-0083> > > 3=
>=3D<BR>> >16-978-3922> > > rodney.bates at wichita.edu> >=
> >> > > --> > > ---------------=3D<BR>> >-------=
>---------------------------------------> > > Rodney M. Bates, reti=
>re=3D<BR>> >d assistant professor> > > Dept. of Computer Sci=
>ence, Wichita State Univers=3D<BR>> >ity> > > Wichita, KS 67=
>260-0083> > > 316-978-3922> > > rodney.bates at wichita=3D<B=
>R>> >.edu> >> >> > Boo! Scare away worms, viruses a=
>nd so much more! Try Windows =3D<BR>> >Live > > OneCare! Try no=
>w!>=3D20<BR>> >___________________________________________________=
>______________<BR>> >Climb to the top of the charts!=3DA0 Play Star S=
>huffle:=3DA0 the word scramble =3D<BR>> >challenge with star power.<B=
>R>> >http://club.live.com/star_shuffle.aspx?icid=3D3Dstarshuffle_wlma=
>iltextlink_oc=3D<BR>> >t=3D<BR>> ><BR>> >--_0109391c-2ffe=
>-4cfe-9165-c2a24628c3c7_<BR>> >Content-Type: text/html; charset=3D"is=
>o-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> &=
>gt;<BR>> ><html><BR>> ><head><BR>> ><style=
>><BR>> >.hmmessage P<BR>> >{<BR>> >margin:0px;<BR>>=
> >padding:0px<BR>> >}<BR>> >body.hmmessage<BR>> >{<BR>=
>> >FONT-SIZE: 10pt;<BR>> >FONT-FAMILY:Tahoma<BR>> >}<BR>&=
>gt; ></style><BR>> ></head><BR>> ><body class=
>=3D3D'hmmessage'>But if I don't want to pay for heap allocation, I=3D<BR=
>>> > can't say:<BR><BR>> > <BR><BR>> &g=
>t;VAR T: v;<BR><BR>> > <BR><BR>> ><FONT fa=
>ce=3D"">v.<FONT face=3D"">DoSomething</FONT></FONT>();<BR><BR>> &g=
>t; <BR><BR>> >Only IMPORT T FROM M;<BR><BR>> =
>> <BR><BR>> >VAR T: v;<BR><BR>> >&n=
>bsp;<BR><BR>> >M.DoSomething(v);<BR><BR>> >&nbs=
>p;<BR><BR>> >Right?<BR><BR><BR>> >SPIN I thin=
>k you mean.<BR><BR>> >Anyone build it and bring it up? I was lo=
>ng curious but never did..<BR><BR>> > <BR><BR>&g=
>t; > - Jay<BR><BR><BR><BR>> ><BR>> &=
>gt;<HR id=3D3DstopSpelling><BR>> ><BR><BR>> >&g=
>t; CC: m3devel at elegosoft.com<BR>> From: darko at darko.org<BR&=
>gt;> Subjec=3D<BR>> >t: Re: [M3devel] small array in modula-3?=
><BR>> Date: Thu, 15 Nov 2007 20=3D<BR>> >:29:06 -0800<=
>;BR>> To: jay.krell at cornell.edu<BR>> <BR>&=
>gt; Not sure wh=3D<BR>> >at the problem is with modules. If you want =
>to avoid the <BR>> dot you c=3D<BR>> >an name the type s=
>omething unique then import that type <BR>> name. You =3D<BR>&=
>gt; >can create an interface with all the nice type names and <BR>=
>> import al=3D<BR>> >l those names in modules by adding an EXP=
>ORTS clause too.<BR>> <BR>> =3D<BR>> >Perso=
>nally I think M3, with a couple of extensions, wouldn't need <BR>&=
>;gt; =3D<BR>> >unsafe anything. The unsafe features are there mostly =
>because of <BR>> l=3D<BR>> >egacy interfaces. I forget t=
>he name but the folk who wrote an OS in <BR>>=3D<BR>> >; =
>M3 found it very effective with only couple of minor points with <BR>=
>>=3D<BR>> > regards to interfacing to C code they built on top=
> of, I think one of <BR>=3D<BR>> >> them was being able =
>to pass NIL to a VAR parameter, which is a common =3D<BR>> ><BR>=
>;> C idiom (and an annoying one for M3 users who then can't use VAR)=
>.=3D<BR>> ><BR>> <BR>> <BR>> O=
>n 15/11/2007, at 8:08 PM, Jay wrote:<BR>> <B=3D<BR>> >=
>;R>> > Rodney, thank you, this is interesting.<BR>&a=
>mp;gt; > I definite=3D<BR>> >ly don't want to pay for heap all=
>ocation for a tiny array.<BR>> > I d=3D<BR>> >on'=
>t know about "subarray". It looks like it takes and returns <BR>&=
>gt; >=3D<BR>> >; arrays. It's not a type. I ordered another cop=
>y of the Nelson book <BR>&g=3D<BR>> >t; > so I don't=
> have to find mine.<BR>> ><BR>> > G=
>ood idea "=3D<BR>> >MakeT" I forgot about that pattern. I'll try it o=
>ut.<BR>> ><BR>> &=3D<BR>> >gt; T=
>he record and array I propose are not all that different really.<BR>&=
>amp;g=3D<BR>> >t; > I just heard of something new. Have you he=
>ard of it? "Duck typing".=3D<BR>> > <BR>> > If it=
> acts/quacks/walks like a duck, it is a duck.<BR>> &=3D<BR=
>>> >gt; This is in very dynamic languages like Ruby.<BR>>=
>; > You apply obj=3D<BR>> >ect.method and if object defines so=
>mething named <BR>> > "method", th=3D<BR>> >en it=
> "must" have "the" meaning you intend.<BR>> > Kind of l=
>ike how C=3D<BR>> >++ templates "accept as parameters whatever <BR=
>>> > happens to work".=3D<BR>> ><BR>> &=
>amp;gt;<BR>> > Operator overloading is great for string=
>s and "m=3D<BR>> >ath".<BR>> ><BR>> =
>> Maybe I should try to have this language de=3D<BR>> >bate fr=
>om scratch again..?<BR>> ><BR>> > I=
> still am conflcted.<=3D<BR>> >BR>> ><BR>&a=
>mp;gt; > Modules seem overly heavyweight.<BR>> >=
> I d=3D<BR>> >on't want Module1.T, Module2.T, I want T1, T2.<BR>=
>;> ><BR>> > C+=3D<BR>> >+ stack str=
>ucts with non virtual member functions:<BR>> > class Re=
>ct_=3D<BR>> >t<BR>> > {<BR>> >=
>; Rect_t() : top(0), left(0), right(0), bottom(=3D<BR>> >0) { }<BR=
>>> ><BR>> > int Height() { return bott=
>om - top; }<BR>&=3D<BR>> >gt; > int Width() { return=
> right - left; }<BR>> > int top, left, b=3D<BR>> >=
>;ottom, right;<BR>> > };<BR>> ><=
>BR>> > seems "good".<BR>&g=3D<BR>> >t; &am=
>p;gt;<BR>> > And it seems not really all that complicat=
>ed for the c=3D<BR>> >ompiler to <BR>> > flow the=
> static type information around to resolve=3D<BR>> > the functions..&=
>lt;BR>> ><BR>> > Rect_t r;<BR>&a=
>mp;gt; > r.Height(=3D<BR>> >) =3D3D> Rect_Height(&a=
>mp;r); ..and would be inlined anyway.<BR>> ><=3D<BR>=
>> >BR>> > I do find some compelling features in Modu=
>la-3. Mainly that it=3D<BR>> > <BR>> > compiles t=
>o native code and has OPTIONAL safety, optional ga=3D<BR>> >rbage <=
>;BR>> > collection, and that the syntax of modules/interfa=
>ces a=3D<BR>> >llows fast <BR>> > compilation -- =
>no longer reparsing the same header=3D<BR>> >s over and over <BR&g=
>t;> > and over and over.<BR>> ><BR>=
>> > =3D<BR>> >Operator overloading btw..have seen "temp=
>late SafeInt"? It acts <BR>> &g=3D<BR>> >t; like a p=
>rimitive integer, but raises exceptions upon overflow.<BR>> &a=
>mp;=3D<BR>> >gt; For this to work very much requires operator overloa=
>ding.<BR>> ><=3D<BR>> >BR>> >=
> A point, of course, is to be able to have user defined types t=3D<BR>> =
>>hat <BR>> > can act like the built in types..<BR=
>>> ><BR>> &g=3D<BR>> >t; - Jay<B=
>R>> ><BR>> ><BR>> >=
>; > Date: Thu, 15 Nov 2007=3D<BR>> > 18:39:18 -0600<BR>&=
>amp;gt; > > From: rodney.bates at wichita.edu<BR>> =
>&g=3D<BR>> >t; > To: m3devel at elegosoft.com<BR>&g=
>t; > > Subject: Re: [M3devel] =3D<BR>> >small array in =
>modula-3?<BR>> > ><BR>> > &a=
>mp;gt; Jay wrote:<BR>=3D<BR>> >> > ><BR=
>>> > > > What is the right way to have a var=
>ia=3D<BR>> >bly sized but always small <BR>> > ar=
>ray in Modula-3?<BR>> > &g=3D<BR>> >t; &g=
>t; My array will only ever have 1 or 2 elements.<BR>> >=
> > >=3D<BR>> >; I'd like to always allocate room for 2 e=
>lements, and have there <BR>> =3D<BR>> >> be a si=
>ze.<BR>> > > ><BR>> >=
> > > It seems I ha=3D<BR>> >ve a choice of<BR>&am=
>p;gt; > > ><BR>> > > &g=
>t; a) an "open" a=3D<BR>> >rray<BR>> > >&l=
>t;BR>> > > Heap allocated, I presume? If the =3D<BR=
>>> >max size is only 2 elements,<BR>> > > =
>this is pretty extravagant, =3D<BR>> >as a heap allocated open array =
>will<BR>> > > have 4 extra behind-t=3D<BR>> &=
>gt;he-scenes words of space overhead, plus<BR>> > &=
>gt; maybe heap fragme=3D<BR>> >ntation, and time overhead of allocati=
>on,<BR>> > > collection, and=3D<BR>> > may=
>be reduced locality of reference.<BR>> > ><BR=
>>> > > &=3D<BR>> >gt; b) wrap it up in a =
>record<BR>> > > ><BR>> &=
>gt; > >=3D<BR>> > I'd like so have, like:<BR>&=
>;gt; > > ><BR>> > > >=
>; TYPE=3D<BR>> > A =3D3D ARRAY [0..1] OF FOO;<BR>> &=
>gt; > ><BR>> > > > A=3D<BR>=
>> >nd be able to say:<BR>> > > ><=
>;BR>> > > > VAR<BR>>=3D<BR>> =
>>; > > > a : A;<BR>> > >=
> ><BR>> > > > ..<BR=3D<BR>> =
>>>> > > > a.size<BR>> &g=
>t; > > FOR i :=3D3D 0 TO a.size D=3D<BR>> >O<BR>&=
>amp;gt; > > > do something with a[i]<BR>>=
> > > ><BR>&=3D<BR>> >gt; > &=
>;gt; > It seems I have no option but, like:<BR>> &g=
>t; > &=3D<BR>> >gt;<BR>> > > &a=
>mp;gt; TYPE A =3D3D RECORD<BR>> > > > a: =
>ARRA=3D<BR>> >Y[0..1] OF FOO;<BR>> > > &am=
>p;gt; size :=3D3D 1; (* usually of size 1, s=3D<BR>> >ometimes 2 *)&l=
>t;BR>> > > > END<BR>> > =
>> ><BR>> >=3D<BR>> >; > &=
>gt; and then<BR>> > > > FOR i :=3D3D 0 TO=
> a.size DO<BR>&g=3D<BR>> >t; > > > do =
>something with a.a[i];<BR>> > > ><BR&g=
>t;> =3D<BR>> >> > > That is "ok". Not gre=
>at -- what to call the inner a?<BR>>=3D<BR>> > > =
>> > But then furthermore, I'd like to construct constants.<=
>;BR>&=3D<BR>> >gt; > > > It seems I am st=
>uck with either the verbose:<BR>> >=3D<BR>> >; &am=
>p;gt; ><BR>> > > > PROCEDURE F(a:A=
>);<BR>> > > >=3D<BR>> ><BR>&a=
>mp;gt; > > > F( A { ARRAY[0..1] OF FOO { .. } );<BR=
>>> > &g=3D<BR>> >t; ><BR>> &=
>amp;gt; > > OR I have to come up with a name for the emb=3D<B=
>R>> >edded array.<BR>> > > > But of=
> course, its type is really "the =3D<BR>> >same" as the outer type.&l=
>t;BR>> > ><BR>> > ><B=
>R>> > &=3D<BR>> >gt; Ignoring the fact that the =
>types are different linguistically<BR>> &=3D<BR>> >g=
>t; > (one a record type, the other an array), the types are differen=
>t<B=3D<BR>> >R>> > > at a deep semantic le=
>vel too. The inner array has static<B=3D<BR>> >R>> &=
>gt; > size, the outer one (call it a "variable array", perhaps)<=
>=3D<BR>> >BR>> > > has dynamically changeable=
> size, even more easily changed=3D<BR>> ><BR>> > =
>> after it is created than a heap-allocated open array. Th=3D<BR>>=
>; >is<BR>> > > is a significant semantic diff=
>erence, so it also makes=3D<BR>> > program<BR>> >=
> > design sense to view them as different types.<BR=3D<BR>> &g=
>t;>> > ><BR>> > > &g=
>t;<BR>> > > > To wit:<BR>&g=3D<=
>BR>> >t; > > ><BR>> > &g=
>t; > TYPE FooArray =3D3D ARRAY[0..1] OF F=3D<BR>> >oo;<BR&g=
>t;> > > ><BR>> > > &=
>amp;gt; TYPE FooArray =3D3D RECORD<=3D<BR>> >BR>> &g=
>t; > > a : FooArray;<BR>> > > &=
>;gt; size :=3D3D 1;<BR=3D<BR>> >>> > > &am=
>p;gt; END;<BR>> > > ><BR>> &=
>amp;gt; > > F( =3D<BR>> >FooArray { FooArray { .. } );&=
>lt;BR>> > > ><BR>> > &am=
>p;gt; >=3D<BR>> > But I have to come up with different names.&=
>lt;BR>> > > ><BR>>=3D<BR>> &=
>gt; > > > And I don't think I can leave out the name f=
>or the construc=3D<BR>> >tor, <BR>> > like:<BR=
>>> > > ><BR>> > >=
> > F( F=3D<BR>> >ooArray { { .. } );<BR>> >=
>; ><BR>> > ><BR>> > &=
>amp;gt; Y=3D<BR>> >es, this is a limitation in Modula-3. Ada allows v=
>alue constructors<BR>>=3D<BR>> > > > to om=
>it inner type names in cases like this, and it is <BR>> =3D<BR=
>>> >> convenient. But<BR>> > > it a=
>lso crosses a really major line =3D<BR>> >on complexity of the langua=
>ge <BR>> > semantics,<BR>> > &g=
>t; si=3D<BR>> >nce type analysis information now flows not only upwar=
>d, but <BR>> > =3D<BR>> >also downward<BR>&=
>amp;gt; > > in expression typing. I am mostly content t=3D<BR=
>>> >o live with this as <BR>> > one bit of<BR&=
>gt;> > > the price of=3D<BR>> > avoiding a horri=
>bly over complex language.<BR>> > ><BR>&am=
>p;gt; > =3D<BR>> >> Ordinary procedures can do pretty m=
>uch all of the things done by <BR>&=3D<BR>> >gt; > e=
>xotic<BR>> > > and complex language stuff like C=
>++ const=3D<BR>> >ructors. If you don't <BR>> > w=
>ant to write<BR>> > > the pon=3D<BR>> >der=
>ous nested value constructor, write a constructor <BR>> &g=
>t; procedur=3D<BR>> >e and<BR>> > > call i=
>t. As Antony suggested, you can make it accep=3D<BR>> >t an open <=
>BR>> > array formal,<BR>> > > w=
>hich then codes ju=3D<BR>> >st like a simple array value constructor.=
> You <BR>> > could even<BR>&=3D<BR>> >g=
>t; > > make it elaborate and general, e.g.:<BR>>=
> > ><BR>>=3D<BR>> >; > > PROC=
>EDURE MakeF ( Val : ARRAY OF FOO ) : F<BR>> > >&=
>lt;BR=3D<BR>> >>> > > =3D3D VAR LSize : CARDI=
>NAL<BR>> > > ; VAR LResult : =3D<BR>> >A&l=
>t;BR>> > ><BR>> > > ; BE=
>GIN<BR>> > > LSize :=3D3D =3D<BR>> >NUMBER=
> ( Val )<BR>> > > <* ASSERT LSize <=
>;=3D3D NUMBER ( FooArr=3D<BR>> >ay ) *><BR>> &=
>;gt; > ; LResult . size :=3D3D LSize<BR>> > &=
>;gt; =3D<BR>> >; SUBARRAY ( LResult . a , 0 , LSize )<BR>&g=
>t; > > :=3D3D SUBARRAY ( Va=3D<BR>> >l , FIRST ( Val ) =
>, LSize )<BR>> > > ; RETURN LResult<BR>&am=
>p;gt; >=3D<BR>> > > END MakeF<BR>> >=
>; ><BR>> > > Alternatively, since yo=3D<B=
>R>> >ur maximum element count is so small, you <BR>> &am=
>p;gt; could<BR>> > =3D<BR>> >> write a con=
>structor procedure that took two formals of type FOO, <BR>&=3D<BR=
>>> >gt; > with<BR>> > > at least th=
>e second one optional. (This wou=3D<BR>> >ld require a <BR>&=
>;gt; > distinguished<BR>> > > value of ty=
>pe FO=3D<BR>> >O that would be used to mean "omitted".)<BR>&=
>;gt; > ><BR>> > >=3D<BR>> >; =
>And, of course, if you want to use abstraction, you can put the <BR>&=
>amp;gt; =3D<BR>> >> types,<BR>> > >=
> constructor procedures, and various other pro=3D<BR>> >cedures for &=
>lt;BR>> > manipulating<BR>> > >=
> the variable sized=3D<BR>> > array in a module, behind an interface.=
><BR>> > ><BR>> > >=3D<=
>BR>> >; An additional limitation of Modula-3 in this regard, is that =
>you <BR>>=3D<BR>> > > can't<BR>> &am=
>p;gt; > make the type F opaque, unless you heap alloc=3D<BR>> >=
>;ate it, which we <BR>> > were trying<BR>>=
> > > to avoid. Ada =3D<BR>> >would allow you to do this=
>, but it's another <BR>> > example of<BR>&g=
>=3D<BR>> >t; > > a convenience with high cost. It force=
>s the equivalent of the =3D<BR>> ><BR>> > revelat=
>ion<BR>> > > to be located in the equivalent =3D=
><BR>> >of the interface, but makes it <BR>> > ill=
>egal<BR>> > > to w=3D<BR>> >rite client co=
>de that depends on what the revelation is.<BR>> > &=
>gt;<=3D<BR>> >BR>> > > This in turn create=
>s a source code control nightmare in a=3D<BR>> > large <BR>&=
>;gt; > project,<BR>> > > because now some=
>one who wan=3D<BR>> >ts to make what is really a purely <BR>&am=
>p;gt; > internal,<BR>> > >=3D<BR>> >=
>; implementation change, nevertheless has to check out the <BR>&g=
>t; > in=3D<BR>> >terface, and<BR>> > &=
>gt; if you aren't in denial mode, that means imp=3D<BR>> >lementers o=
>f all the <BR>> > client<BR>> > &am=
>p;gt; code have to go=3D<BR>> > to extra trouble to somehow find out =
>that what <BR>> > appears<BR>&g=3D<BR>> &g=
>t;t; > > to be an interface change actually doesn't affect th=
>em after a=3D<BR>> >ll.<BR>> > ><BR>=
>> > > ><BR>> > > &am=
>p;gt; Though =3D<BR>> >that might seem nice.<BR>> &g=
>t; > ><BR>> > > > Am I un=
>=3D<BR>> >derstanding everything?<BR>> > >=
> ><BR>> > > > Have =3D<BR>> >=
>;folks hit this before and there's a set of names that <BR>> &=
>amp;gt; don't s=3D<BR>> >eem too lame<BR>> > &=
>;gt; > that folks use?<BR>> > > >&=
>lt;=3D<BR>> >BR>> > > > Also -- langua=
>ge documentation?<BR>> > > &g=3D<BR>> >=
>;t; Nelson's green book is excellent.<BR>> > > &=
>amp;gt; The stuff in th=3D<BR>> >e doc directory is very dry and scie=
>ntific.<BR>> > > > The tuto=3D<BR>> &g=
>t;rial seems more like a reference. Or maybe I didn't <BR>> &a=
>mp;gt; read it e=3D<BR>> >nough.<BR>> > > =
>> Is there better, in case I need a refresher?<=3D<BR>> >BR=
>>> > > > I think I got it, via Nelson's book=
> from memory (won=3D<BR>> >der if I <BR>> > can f=
>ind mine..) and the reference,<BR>> > >=3D<BR>>=
>; >; > but I don't think anyone could learn from the current onli=
>ne <BR>>=3D<BR>> >; > docs in the source tree.<=
>BR>> > > ><BR>> > &g=
>t; &g=3D<BR>> >t; Maybe it's me, some combination of laziness and=
> short attention <BR>>=3D<BR>> > > span<BR>=
>> > > > as I age..<BR>> > &=
>amp;gt; ><BR>>=3D<BR>> > > > &g=
>t; Btw, C doesn't offer a great solution here, though it offer=3D<BR>> &=
>gt;s <BR>> > leaving out some type names.<BR>&=
>;gt; > > > In C++ =3D<BR>> >I could have both .s=
>ize and operator[].<BR>> > > > Modula-3 s=
>ee=3D<BR>> >ms to be missing operator overloading.<BR>> =
>> > > It's got some=3D<BR>> > builtin stuff, eve=
>n array assignment and equality <BR>> > and I thin=3D<B=
>R>> >k<BR>> > > > even record assig=
>nment and equality, but it is sti=3D<BR>> >ll a bit <BR>>=
>; > limiting.<BR>> > ><BR>> =
>> ><BR>>=3D<BR>> >; > > I hav=
>e raved on this before, but, having had lots of painful <B=3D<BR>> &g=
>t;R>> > experience with<BR>> > >=
>; user-defined overloading in A=3D<BR>> >da and C++, I can say with &=
>lt;BR>> > authority, that it is<BR>> >=
>=3D<BR>> > > a programming language disaster. It interacts wit=
>h just about <BR>>=3D<BR>> >; > everything<BR&g=
>t;> > > else in the language, in very complicat=3D<BR>=
>> >ed ways, and all it buys <BR>> > you is saving=
><BR>> > > time=3D<BR>> >/energy thinking u=
>p distinct names for procedures/functions. <BR>> > =3D<=
>BR>> >Even this,<BR>> > > aside from the e=
>ffects on the language, is a n=3D<BR>> >et loss, by the <BR>&am=
>p;gt; > time you consider<BR>> > > readab=
>ili=3D<BR>> >ty along with writability.<BR>> > &a=
>mp;gt;<BR>> > > User-defined=3D<BR>> > ove=
>rloaded operators provide a slight readability <BR>> > =
>benefit, _=3D<BR>> >if_<BR>> > > used with=
> great restraint and discipline, something y=3D<BR>> >ou can rely <=
>;BR>> > on not happening.<BR>> > &=
>gt; Meanwhile, th=3D<BR>> >e language complexity can easily double or=
> worse. <BR>> > And, with t=3D<BR>> >he<BR>=
>> > > exception of compiler writers and language lawye=
>rs who=3D<BR>> > spend <BR>> > hundreds of hours&=
>lt;BR>> > > on just this, prog=3D<BR>> >ramme=
>rs don't understand the rules, not even <BR>> > close.&=
>lt;BR>> &=3D<BR>> >gt; ><BR>> &=
>gt; > ><BR>> > > > Also, if=
> I understan=3D<BR>> >d things correctly, this has long bothered <=
>BR>> > me about Modula-3,=3D<BR>> ><BR>>=
>; > > > though I'm more tolerant now -- Modula-3 doesn=
>'t se=3D<BR>> >em to allow <BR>> > for lighter wi=
>eght<BR>> > > > objects=3D<BR>> >. =
>Like, small stack allocated structs with member <BR>> >=
> functions. =3D<BR>> >You seem to have<BR>> > &am=
>p;gt; > to chose between heap allocated gar=3D<BR>> >bage coll=
>ected virtual <BR>> > member functions full<BR>&a=
>mp;gt; > >=3D<BR>> >; > featured objects, or feat=
>ureless dumb structs. It's nice how C+ <BR>=3D<BR>> >> &=
>amp;gt; + allow hybrids --<BR>> > > > obj=
>ects don't have to b=3D<BR>> >e heap allocated and member functions &=
>lt;BR>> > don't have be virtual.<=3D<BR>> >BR>=
>> > > > Or am I missing something?<BR>&am=
>p;gt; > ><BR>>=3D<BR>> > > >=
><BR>> > > C++'s supposedly lighter weight forms =
>of class=3D<BR>> >es/structs with <BR>> > their s=
>pecial<BR>> > > member functi=3D<BR>> >ons=
> buy nothing that plain records, plain <BR>> > procedur=
>es, and<BR>=3D<BR>> >> > > interfaces/modu=
>les don't already provide, again, at signific=3D<BR>> >ant <BR>=
>> > and gratuitous<BR>> > > langua=
>ge complexity. Exc=3D<BR>> >ept when methods/member functions <BR&=
>gt;> > actually dispatch<BR>> &=3D<BR>> &=
>gt;gt; > dynamically, there is nothing that the above won't do, and =
>when <B=3D<BR>> >R>> > you create a<BR>&=
>;gt; > > class instance as a local variab=3D<BR>> >le (=
>i.e., on the stack), it is <BR>> > necessarily<BR>=
>;> > > =3D<BR>> >not polymorphic, that is, it ca=
>n't change its "allocated" or <BR>> > =3D<BR>> >d=
>ynamic type<BR>> > > among various subtypes at r=
>untime. This in t=3D<BR>> >urn means it can't <BR>> &=
>;gt; dispatch.<BR>> > ><BR>> &g=
>t; &=3D<BR>> >gt; So, just use plain procedures, an interface and=
> a module, and you <BR>&=3D<BR>> >gt; > will get<=
>BR>> > > everything a lighter-weight C++ class w=3D=
><BR>> >ould give you.<BR>> > ><BR>&a=
>mp;gt; > ><BR>> > > ><B=
>=3D<BR>> >R>> > > > Anyway, I've gotte=
>n to accept C a bit more vs. C++ so=3D<BR>> > I can <BR>>=
>; > deal with<BR>> > > > t: Type;&=
>lt;BR>> >=3D<BR>> > > > Type_DoSomethi=
>ng(t);<BR>> > > ><BR>> &=
>gt; > &g=3D<BR>> >t; in place of:<BR>> &g=
>t; > > t.DoSomething();<BR>> > >&l=
>t;B=3D<BR>> >R>> > ><BR>> &g=
>t; > Exactly. The special "receiver object" i=3D<BR>> >n a tru=
>e method call has <BR>> > significant<BR>>=
> > > semant=3D<BR>> >ic differences from an ordinary pa=
>rameter and introduces <BR>> > new =3D<BR>> >comp=
>lexities<BR>> > > and non-orthogonalities. It ha=
>s some very va=3D<BR>> >luable uses too.<BR>> > &=
>amp;gt;<BR>> > > But to then create deg=3D<BR>&g=
>t; >enerate forms of it that still carry a lot <BR>> &g=
>t; of these<BR>> &=3D<BR>> >gt; > complexitie=
>s, but are equivalent in programing power to plain old<=3D<BR>> >B=
>R>> > > parameters is just bad program design and b=
>ad language de=3D<BR>> sign. <BR>> > Objects and<=
>BR>> > > methods are indeed cool f=3D<BR>> >o=
>r situations that utilize their <BR>> > semantic comple=
>xity.<BR>>=3D<BR>> > > > But it's deeply u=
>ncool to try to look superficially cool by usin=3D<BR>> >g an<BR&g=
>t;> > > inappropriately sophisticated construct when t=
>he pro=3D<BR>> >blem doesn't <BR>> > justify it.&=
>lt;BR>> > > Some OO proponents=3D<BR>> > have=
> gone way over the deep end here.<BR>> > ><BR=
>>> > > =3D<BR>> >><BR>> &=
>amp;gt; > > - Jay<BR>> > > >=
>;<BR>> > > =3D<BR>> >><BR>&am=
>p;gt; > > > <BR>> > --------------=
>-------------------=3D<BR>> >------------------------------------- &l=
>t;BR>> > --<BR>> > > &g=3D<=
>BR>> >t; Boo! Scare away worms, viruses and so much more! Try Windows=
> <BR>> &g=3D<BR>> >t; Live OneCare! Try now!<BR&g=
>t;> > > <http://onecare.live.com/sta=3D<BR>>=
> >ndard/en-us/purchase/trial.aspx? <BR>> > s_cid=3D3=
>Dwl_hotmailnews><B=3D<BR>> >R>> > >=
><BR>> > ><BR>> > > --=
><BR>> > > -=3D<BR>> >---------------------=
>---------------------------------------<BR>> > &=3D=
><BR>> >gt; Rodney M. Bates, retired assistant professor<BR>&=
>;gt; > > Dept. of=3D<BR>> > Computer Science, Wichita S=
>tate University<BR>> > > Wichita, KS 6=3D<BR>>=
>; >7260-0083<BR>> > > 316-978-3922<BR>&=
>amp;gt; > > rodney.bates at wic=3D<BR>> >hita.edu<BR>=
>;> > ><BR>> > > --<BR>=
>;> > > ---------=3D<BR>> >----------------------=
>------------------------------<BR>> > > Rodn=3D<=
>BR>> >ey M. Bates, retired assistant professor<BR>> &=
>;gt; > Dept. of Compute=3D<BR>> >r Science, Wichita State Univ=
>ersity<BR>> > > Wichita, KS 67260-008=3D<BR>>=
> >3<BR>> > > 316-978-3922<BR>> &=
>amp;gt; > rodney.bates at wichita.edu=3D<BR>> ><BR>>=
> ><BR>> ><BR>> > Boo! Scare =
>away worms, viruses and =3D<BR>> >so much more! Try Windows Live <=
>BR>> > OneCare! Try now!<BR>> <BR>=3D<B=
>R>> ><BR><br /><hr />Climb to the top of the charts=
>!=3DA0 Play Star Shuffle:=3DA0 th=3D<BR>> >e word scramble challenge =
>with star power. <a href=3D3D'http://club.live.com/=3D<BR>> >star_=
>shuffle.aspx?icid=3D3Dstarshuffle_wlmailtextlink_oct' target=3D3D'_new'>=
>Pl=3D<BR>> >ay Now!</a></body><BR>> ></html>=
>=3D<BR>> ><BR>> >--_0109391c-2ffe-4cfe-9165-c2a24628c3c7_--<BR>=
><BR><br /><hr />Help yourself to FREE treats served up daily at the Messeng=
>er Caf=E9. <a href=3D'http://www.cafemessenger.com/info/info_sweetstuff2.ht=
>ml?ocid=3DTXT_TAGLM_OctWLtagline' target=3D'_new'>Stop by today!</a></body>
></html>=
>
>--_85b6c041-9539-4614-b541-8813489e58bb_--
More information about the M3devel
mailing list