headers
David E. Manifold | 4 Sep 1997 13:51

Is this list active?

	Hello, is the Tunes list up?

	I stopped receiving messages from this list sometime early this 
year, and assumed it was shut down.  The reason  I thought this is 
because Fare had made some mention of how the project might need a 
new home starting in June.  Well, when I stopped receiving messages I 
figured the project was probably pretty much dead.. how embarassing 
it would be if I found out somehow I was only accidentally 
unsubscribed?  Have I just been off the list for 4 months?!?

	Somebody please reply, because I am interested in becoming active in 
this project again!  I want to know what has been going on for the 
last 4 months (if anything).

David E. Manifold
dem <at> pacificrim.net
Permalink | Reply | 0 comments |
headers
Patrick Premont | 4 Sep 1997 19:08
Picon

What I've been doing


Hello,

  I haven't been active on the list for quite a while, but I finally
have a little something to contribute. I've finished my Master's
thesis at the University of Toronto. I've said before that its subject
was related to TUNES. Well, it is, but it was not designed as a
contribution to TUNES. 

It's a comparison of two logical formalisms to represent actions and
their effect. One is from knowledge representation in AI and another
from formal programming methods.  I compare and unify the two
formalisms. You can find the thesis at <http://www.cs.utoronto.ca/~premont>
It will probably be difficult to understand without consulting the
references, but if you feel confident in logic you can give it a shot.

It does not provide a logical formalism that is sufficient for the
goals of TUNES: for one thing I didn't select a treatment for time and
concurrency. It does provides an understanding of how we build TUNES
by starting from logic: We can provide a way to logically represent
world phenomena, and from that define programming languages to
accommodate whatever needs we have. That's not an innovative
suggestion, but I think that's the way to go. If I have the time in
the future, I would like to settle on a sufficiently expressive
logical representation, implement that into a theorem prover, specify
logically how the computer works (at least with respect to a subset of
CPU instructions), and build up TUNES from there, proved correct from
the start.

Unfortunately doing this in my free time will be very difficult, so I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fare Rideau | 6 Sep 1997 18:15
Picon
Picon

Back to life

Dear Tunespeople,
   I'm happy to tell you that I'm back to life, after a period of depression,
with my report of DEA (last year before beginning PhD) being finished
(errata and appendices to come), about a reflective proof system for
applicative lambda calculus (very incomplete implementation with a
scheme syntax).

   As a result, after a week of new administratrivia, I'll be back seriously
to Tunes...

To dave: yes, you've been off the list for several months.
 My archive has 78 messages since 19970228. I'll try to update the
 mailing list archive by next week...

To billy: oops, I admit the ASM it's still part of my years-long todo list
 (though in good position). As for embedded Perl in SGML
 (who's to execute it?), I've rather been told about the DSSSL standard,
 with embedded Scheme instead. See the free implementation, JADE, under Linux,
  <at>  .../Review/Languages.html#Scheme

To pat: I'll get your report, too. Congratulations,
 and please keep in touch!

   Regards to you all!

-- #f

PS: in case my report is of any interest to you, see (in french)
files stage_unice* and proof.tgz in
http://www.eleves.ens.fr:8080/home/rideau/files/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jano John Akim Franke | 8 Sep 1997 12:02
Picon
Favicon

some general comments on science and egineering (Re: What I've been doing)

Dear TUNES-people,

Patrick Premonts email inspired me to post some general comments about the
way projects are done today.

We all know what we do not like in existent computing systems, but the
solution IMHO should not be to elliminate these subjects. This is to tell
you why there may be another way.

Through many (man-)years of development both hardware and software new
things almost always dependet on the older ones being compatible to them or
adding a few features and dropping less, the very basic underlying
technology always stayed the same. This is reasonable because why should
you thing about how to do basic things everyone was doing before you
successfully? You can depend on long-prooved methods to get a fast start
for your project without wasting time for things that are optimal and
therefore can not change.

The point is: Maybe there are not as optimal as you think. As time went by
new things (features) were invented so computing systems aren't really what
they were in the 60s but why are we using the same principles as our
grandfathers? They worked fine for their computing machinery but as we see
they are causing problems in todays.

I see a threat in solutions not questioning the very basic roots of this
still young science. When we proceed as we do there is no question that we
may end up with an sub-optimal solution because what we do is like a
heuristic: We fix problems of current technology to a get a better one
leaving a part of it as it was from the beginning of the process. This is
(not fully but) like a heuristic solution-tree. Another science field
(Continue reading)

Permalink | Reply | 0 comments |
headers
David E. Manifold | 13 Sep 1997 18:36

Attributes

I am replying to a message Fare wrote me on May 7.
Because it was so old, I feel justified to quote the whole thing.  I
apologize if this is annoying.
(Also since the archive isn't being updated)
> [Fare]
>> [dem]
>> What is an attribute?  I can't seem to figure out the difference between
>> this and a function.  You say the implementation may make the difference
>> meaningless; but I don't quite understand the theoretical difference.
>>
>An attribute can be conceptually thought of as a memoized function:
>you have a function that associates some abstract value to some objects,
>but want to remember that value permanently without having to recompute it.

The caching of a function result is a separate topic; and is an
implementation detail.  Caching of results can occur on any arbitrary
function; I don't understand how it applies to attributes.  Do you mean that
any cached value is called an attribute?  Do you mean that one example of
implementation of an attribute is a function with its value forcibly cached?

>* If the function is pure, then there is no semantical difference
> between an attribute and a function

The fact that you state this here implies that attributes are more widely
used in the system than I thought; I was under the impression that
attributes were a special case.  In any situation, an object has the same
semantics as a function if the function is pure.  For example, in C a
function that returns type int can be used anywhere an int can.  Similarly,
but to a greater extent in Tunes, you will be able to use functions and
objects interchangeably.
(Continue reading)

Permalink | Reply | 502 comments |
headers
Alaric B. Williams | 15 Sep 1997 23:16
Picon
Picon

Re: Attributes


> To confirm my understanding of purity, a function is pure if it only
> performs actions necessary to its purpose.  For example if a function is to
> calculate a result, it doesn't also create a persistent variable somewhere
> that remains when the function exits.

Hmmm... I think that skirts the crucial point somewhat. Purity is 
sometimes the topic of flamewars, but the general idea is that this 
is not a pure function:

int LastSum = 0;

int running_sum(int x) {
   return (LastSum += x);
}

since it matters what order the calls occur in:

running_sum(1) => 1
running_sum(10) => 11

but

running_sum(10) => 10
running_sum(1) => 11

IE, with impure functions, you have to be careful what is called 
where. Impure functions compute [some aspect of] their return value 
from a mutable value that is not local to the function - for example, 
this function is really pure, although it does dirty stuff inside, it
(Continue reading)

Permalink | Reply | 503 comments |
headers
William Tanksley | 16 Sep 1997 05:55
Favicon

Re: Attributes

On Mon, 15 Sep 1997, Alaric B. Williams wrote:

> > To confirm my understanding of purity, a function is pure if it only
> > performs actions necessary to its purpose.  For example if a function is to
> > calculate a result, it doesn't also create a persistent variable somewhere
> > that remains when the function exits.

> Hmmm... I think that skirts the crucial point somewhat. Purity is 
> sometimes the topic of flamewars, but the general idea is that this 
> is not a pure function:

I had thought that pure functions were a fairly well defined concept, so
that a function is pure if and only if every call of it with identical
(formal) parameters will produce identical results.

Of course, this probably isn't correct, since this would allow a function
which only modified global variables (which would then be used by other
functions).  So let's add the requirement.

> ABW

-Billy
Permalink | Reply | 0 comments |
headers
Fare Rideau | 16 Sep 1997 19:56
Picon
Picon

Re: Attributes

>>>: dem
>>: Fare [May 7]
>: dem [Sept 14]

> (Also since the archive isn't being updated)
Oops. I'll try to fix that tomorrow morning.

>>An attribute can be conceptually thought of as a memoized function:
>>you have a function that associates some abstract value to some objects,
>>but want to remember that value permanently without having to recompute it.
>
> The caching of a function result is a separate topic; and is an
> implementation detail.
>
look at the following Scheme definition:
(define (memoize fun)
   (let ((table (make-hash)))
	(lambda args
	   (if (memoized? table args)
	       (memoized-value table args)
	       (let ((value (apply fun args)))
		  (memoize! table args value)
		  value)))))
Well, then
* for any pure deterministic function f, f and (memoize f) are equivalent.
* for most (impure) functions f, (memoize f) is different from f
* memoize is idempotent (i.e. (== (memoize f) (memoize (memoize f))))
* the image set of functions returned by memoize is strictly contained
 in that of all functions.
* a memoized function might still do observable side-effects,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alaric B. Williams | 16 Sep 1997 23:43
Picon
Picon

Re: Attributes

> I had thought that pure functions were a fairly well defined concept, so
> that a function is pure if and only if every call of it with identical
> (formal) parameters will produce identical results.
> 
> Of course, this probably isn't correct, since this would allow a function
> which only modified global variables (which would then be used by other
> functions).  So let's add the requirement.

Ah, well - but a function that "leaves a record" would surely still 
be pure, just functions that reference that record would then be 
impure, right? There's a shade of purity. A function that marks in a 
log every application might be considered pure for reasons of 
analysing the code produced by a compiler to see if it memoises 
correctly and stuff like that... but if the function is being used 
more as a setter - ie, the mutation is part of it's "exported" 
semantics - then, indeed, it isn't quite pure any more. The 
difference there is hard to define, no? :-)

> -Billy

ABW
--
Alaric B. Williams Internet : alaric <at> abwillms.demon.co.uk
http://www.abwillms.demon.co.uk/
Permalink | Reply | 5 comments |
headers
William Tanksley | 17 Sep 1997 00:59
Favicon

Re: Attributes

On Tue, 16 Sep 1997, Alaric B. Williams wrote:

> > I had thought that pure functions were a fairly well defined concept, so
> > that a function is pure if and only if every call of it with identical
> > (formal) parameters will produce identical results.

> > Of course, this probably isn't correct, since this would allow a function
> > which only modified global variables (which would then be used by other
> > functions).  So let's add the requirement.

> Ah, well - but a function that "leaves a record" would surely still 
> be pure,

I don't see that.  If the function leaves a record then that record must
have some use, and thus the function cannot be memoized.

> just functions that reference that record would then be impure, right?

Clearly.

> There's a shade of purity. 

No.  Purity is absolute -- 99% pure is really 1% impure, not pure at all.
If a function is almost pure we can't memoize it at all.

Of course, if the behaviour of the function is well-defined it's easier to
manage.

> A function that marks in a 
> log every application might be considered pure for reasons of
(Continue reading)

Permalink | Reply | 3 comments |

Gmane