Newsgroups: comp.lang.misc
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!nuchat!sugar!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Subject: Re: Dynamic typing (part 3)
Message-ID: <QQAAG21@xds13.ferranti.com>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
References: <815@optima.cs.arizona.edu> <W+3AE38@xds13.ferranti.com> <20MAR91.08580313@uc780.umd.edu> <JT4AE6F@xds13.ferranti.com> <21MAR91.23594992@uc780.umd.edu> <IA6A5Q4@xds13.ferranti.com> <22MAR91.20485982@uc780.umd.edu> <039AIL3@xds13.ferranti.com> <26MAR91.18541581@uc780.umd.edu>
Date: Wed, 27 Mar 91 18:45:05 GMT

In article <26MAR91.18541581@uc780.umd.edu> cs450a03@uc780.umd.edu writes:
> Umm.. I like the Peter/Paul style, but my name starts with an 'R'
> (other than that, pronounced like Paul).

Oops.

> (2) I generally don't need to make state machines.  When I do, I try
> to represent the machine as a single data object (the machine state)
> which is mapped by a simple function from one state to another.
> Another thing is that usually, I'll want a history of the machine, so
> each state is stored in a separate location.  In functional
> programming, there is a significant difference between initialization
> and re-assignment.

Hmmm. looks like we're dealing with radically different problem spaces.
You deal with problems where it's desirable and possible to avoid information
loss.  I have to deal with that entropy and give up reversibility to allow
unlimited runtime with limited memory storage. This is particularly important
in interactive programs.

> When you're used to it, C statements like
>     for (j=0; j<max ; j++) { list[j] = f(list[j], j); }
> seem pretty simple.  However, they aren't much faster than
>     new = (type *) malloc( ... );
>     for (j=0; j<max ; j++) { new[j] = f(list[j], j); }
>     free(list);

It may not be significantly slower, but it uses up significantly more
memory. If list is large enought that can easily make the difference between
being able to run the program and not.

Also, I tend to work through dynamically allocated lists, or even lists
that are implicitly defined. In that case "max" is unknown and potentially
unbounded.

	while(msg = GetMsg(port)) {
		switch(msg->request) {
			...
			case FOO:
				state = BAR;
		}
		Reply(msg);
	}

I don't care how GetMsg is implemented, or Reply, but I do need to assume
that there is no limit on the number of times this loop will be run through.
This means I *have* to discard old state information.

>    In fact, since C makes it so awkward to dynamically allocate result
> arrays, people often go to various tree structures when it would be
> more efficient to store the results as a flat array.

This is a limitation in the standard library: it doesn't have a "sack of
data" set of routines. Other C runtime libraries do have such things.

> Most of the time, you can provide that functionality in some
> primitive, and get on with solving the big problems.

That's true, but I don't see how it relates to this question. This is
the smart way to operate in any langauge, no matter how the type rules
work.

> >Raul> [refering to descriptive comments as type declarations]
> >Peter>But wouldn't it be nice if the language understood those declarations?
> >Raul> Then they'd be code.  
> >That's the point.

> Would you settle for a language which provided no special syntax for
> comments (i.e. where comments are just pieces of data that you throw
> into the program)?

Regarding what?
-- 
Peter da Silva.  `-_-'  peter@ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"
