-------------------------------------------------------------------------------
Date: Thu, 26 Aug 1993 18:11:22 +0200 (MET DST)
From: dack@darmstadt.gmd.de (Sven C. Dack)
Subject: Re: closures (fwd)
To: duening@ibr.cs.tu-bs.de (Lars Duening),
        petri@ibr.cs.tu-bs.de (Stefan Petri)

Hi!

Hier ist  die Antwort auf die Fragen, die ich  an Amylaar und  Macbeth
bzgl.  closures hatte (vorerst nur Amylaars Antwort):

(Am besten auch mal den clsoures Text von Mac anschauen, da sich viele
Fragen an diesen Text richten)

---

> >     ({ #'?, cond1, val1, cond2, val2, ..., condn, valn, valdefault });
>
> Hmm, dem beispiel zu Folge waere:
>   cond1 = ({ #'>, 'x, 'y })
>   val1  = 'x
>   cond2 = 'y ??
> oder ist 'y der valdefault? (Scheint jedenfalls so zu sein, aber doch
> etwas verwirrend)

valdefault.

> > while #'? is somewhat like an if statement, #'?! resembles an if_not
> > statement if there were one.

Naja, if (! ist ja auch nur ein zeichen mehr als if( ... und alles compiliert
zu einem einzigen branch.

> >    ({ #'member_array, 'x, '({ "abc", "xyz }) }). Applying lambda() to
> >    this will not result in an error. Instead, the quote will be stripped
> >    from the array and the result regarded as a normal array literal. The
> >    same can be achieved by using the efun quote(), e.g.:
> >    ({ #'member_array, 'x, quote( ({ "abc", "xyz }) ) })
>
> Hmm, Amylaar sagte was auf dem TubMud Meeting in Kirkel, dass man mit
> apply() oder funcall() an den Inhalt von einem quoted array kommt. Irgendwie
> scheint es nicht zu funktionieren.

Sorry, hab' da was durcheinander gebraucht. Um von dem gequoteten wert q
ein quote wergzunehmen, macht man funcall(lambda(0, q)) .
Einfacher ist es, alle quotes von dem array zu nehmen: to_array(q)

> Wenn ich z.B. eine lfun query_property(prop_name) habe und dann am Ende
> der Funktion return funcall(prop_val) mache, ist es sinnvoll/gefaehrlich
> im Falle einer unbound closure noch ein bind_lambda() einzubauen?

Es ist gefaehrlich, wenn die Rechte des Objects, dass bind_lambda() macht,
nicht in der Schinttmenge der Rechte der Objecte liegt, die die closure
erzeugt haben koennten.

> Erzwingt symbol_function() ein Laden des Objects? Die closure die zurueck ge-
> geben wird ist wohl dann auch nur solange existent, wie das Object.

Ja. Jein. Die closure wird durch das Destructen des Objects unbrauchbar.

> > g) Can I create efun closures dynamically, too?
> >    Yes, just use symbol_function() with a single argument. Most useful
> >    for marker objects and the like. But theoretically a security risk
> >    if not used properly and from inside a security relevant object.
> >    Take care, however, that, if there is a simul_efun with the same
> >    name, it will be preferred as in the case of #'function. Use the
> >    efun:: modifier to get the efun if you need it.
> >
> > h) Are there other uses of closures except using them to store code?
> >    Lots. For example, you can use them within almost all of the
> >    efuns where you give a function as an argument, like filter_array(),
> >    sort_array() or walk_mapping(). sort_array(array,#'>) does indeed
> >    what is expected. Another application is set_prompt(), where a
> >    closure can output your own prompt based on the current time and other
> >    stuff which changes all the time.
> >
> > Finally, there are some special efun/operator closures:
> >
> > #'[ indexes an array.
> > #'[< does the same, but starting at the end.
> > #'negate is for unary minus.
> > #', may be followed by any number of closures,
> > e.g.: ({ #', ({#'= 'h, 'a, }), ({#'=, 'a, 'b }), ({#'=, 'b, 'h }) })
> > will swap 'a and 'b when compiled and executed.
>
> Aeh, was ist #' das genau? Closure einer closure?
>
> Nun noch ein paar zusaetzliche Fragen:
>
> - Was ist schneller:
>     strs = map_array(strs, #'lower_case);
>   oder:
>     for(i = sizeof(strs); i--; )
>       strs[i] = lower_case(strs[i]);

Die Iteration in LPC ist wohl schneller.
>
> - Anderes Beispiel:
>     func(arg) { ... }
>       ...
>       arr = map_array(arr, "func", this_object());
>       ...
>   oder:
>     closure cl;
>     cl = lambda(({ 'arg }), ... ); /* tut dasselbe, wie die lfun func() */
>     arr = map_array(arr, cl);

Der aufruf von lambda() kostet erstmal etwas Zeit, wieviel, hangt von der
komplexitaet des ausdrucks ab. Der funktionsaufruf einer closure duerfte
jedoch noch einen tick schneller sein als der von einer lfun, die im
cache ist.

> - Mal abgesehen von der Performance: was ist Programcode-aufwendiger? Welche
>   Variante schraubt den Speicherverbrauch eines Objects in die Hoehe?

map_array in Zusammenhang mit efun/lfun closure Konstanten macht
kompakteren Code. lambda() hingegen braucht manchmal einigen programmcode
extra fuer die argumente. Dafuer spart man sich einen eintrag in der
funktionstabelle, was bei oft inheriteten objecten wichtig ist.
Bei wenig inheriteten objecten sollte man hingegen ueberlegen, ob man die an
lambda() uebergebenen arrays in eine initialisierte globale variable schreibt.

> - Ich vermute auch mal, dass map_array(arr, #'func) immer schneller ist, als
>   map_array(arr, "func", this_object()).

Ja. Dafuer werden shadows ignoriert...

> - set_prompt() nimmt also auch closures an. Fuer welche efuns gilt das noch?
>   (Mal abgesehen von den offensichtlichen map_ und filter_ efuns).
>   call_out()? input_to()? ed()? Falls nein, wuerde sowas eigentlich moeglich/
>   sinnvoll sein?

call_out() nimmt closures. Die Frage nach dem Sinn fuer andere efuns gebe ich
weiter...

> - Wird es sowas wie this_closure() geben? Also wenn man innerhalb einer
>   closure this_closure() aufruft, dass dann diese zurueck geliefert wird.
>   (Naja, ich seh schon, ist etwas bloed die Idee, waere aber in Verbindung mit
>   call_out() interessant ... falls moeglich)

Dazu waere zusaetzlicher overhead erforderlich. Wenn z.B. eine BOUND_LAMBDA
closure aufgerufen wird, sieht das im control stack genauso aus wie eine
LAMBDA closure.
Hmm, gibt es da ausserdem noch security Probleme?

> - Was ist, wenn man einer closure sich selbst uebergibt? Kann sowas dazu
>   fuehren, dass die closure nicht ge-freed wird? (also sowas aehnliches wie
>   selbst-referenziernde Arrays).

I.d.R. macht man sowas, um Rekursion zu realisieren. Natuerlich kann man
die closure auch in einem array speichern, dass zur closure gehoert. Dann
hat man in der Tat eine rekursive Referenz.

        Joern

---

Am interessantesten  ist, dass laut Amylaar eine Iteration  "von Hand"
schneller  ist, als map_array()  mit  einer Closure  und das  wiederum
schneller  als  map_array()  mit dem  Funktionsnamen als String (wobei
letztere wohl zu erwarten waren).

Sven

-------------------------------------------------------------------------------
Date: Tue, 12 Oct 93 21:07:45 +0100
From: duening@ibr.cs.tu-bs.de (Lars Duening)
To: amylaar@cs.tu-berlin.de
Subject: Wunsch zum GD

Hi!

Es waere eine gute Idee, taete der GD unterscheiden zwischen 'Laden
durch Inherit' und 'Laden durch Gebrauch'.

Wir haben in NF den Fall, dass Objekte, die aktiv im Spiel sind, als
Eltern fuer weitere Inheritance herhalten muessen.
Werden nun die Kinder zuerst angefasst, werden die Eltern zwar geladen
(compiliert), aber nicht initialisiert (deren create() wird ja nur fuer
die Kind-Variablen aufgerufen).

Das macht sich dann boes bemerkbar, sobald die Eltern als Objekte ins
Spiel kommen: der GD sieht sie als geladen an, und merkt nicht, dass
sie nicht initialisiert wurden.

Ich sehe zwei Loesungen: einmal das aktive Verwenden von Blueprints
verbieten; oder aber beim Anfassen einer geladenen, aber nicht
initialisierten Blueprint deren create() nochmal aufrufen
(O_NOT_INITIALISED).

Nebenbei: frueher wurden doch die Blueprints gleich mit initialisiert
 - wann hat sich das denn geaendert?

  Lars

-------------------------------------------------------------------------------
Date: Wed, 13 Oct 1993 06:26:05 +0100 (MET)
From: amylaar@meolyon.hanse.de (Joern Rennecke)
Subject: Re: Wunsch zum GD
To: duening@ibr.cs.tu-bs.de

> (O_NOT_INITIALISED).

Das Problem mit den Flags ist, dass sie recht knapp sind...

> Nebenbei: frueher wurden doch die Blueprints gleich mit initialisiert
>  - wann hat sich das denn geaendert?

Das gehoert zum native mode.

        Joern

-------------------------------------------------------------------------------
Date: Wed, 3 Nov 93 21:22:19 +0100
From: duening@ibr.cs.tu-bs.de (Lars Duening)
To: brenner@tat.physik.uni-tuebingen.de,
        dack@darmstadt.gmd.de.petri@ibr.cs.tu-bs.de
Subject: dumpstat aufgebohrt

Hi!

Ich hab das dumpstat() mal aufgebohrt, auf dass es jedes
Array/Mapping/SharedString wirklich nur einmal mitzaehlt.
Die Tests lieferten sinnvolle Zahlen, von daher nehme ich an, dass es
funktioniert.

Im OBJ_DUMP steht jetzt sowas:

obj/tool/xtool#4       960   760 (    0) ref 436    std/player#1 (0)
obj/tool/xtool       22168 21796 (21208) ref 108    -- (0)

Die erste Zahl ist der alte Wert, die zweite Zahl ist die mit jedem
Array nur einmal gezaehlt. Die dritte Zahl ist der Overhead fuer die
Blueprint selber (Programmcode+Funktionstabellen).

Die zweite Zahl ist ein bisschen mit Vorsicht zu geniessen, da die nur
einmal gezaehlten Sachen dem Objekt zugeordnet werden, bei dem sie das
erste mal aufgefuehrt werden. Doch leider kann man mehrfache
Referenzen leider erst ab der zweiten Referenz sicher erkennen - und
da noch ein Backpatching einzubauen ("Mapping# shared by obj/tool/foo,
std/player#69,...") hatte ich keine Lust mehr.

 -- Lars

-------------------------------------------------------------------------------
Date: Tue, 9 Nov 93 19:13:16 +0100
From: petri@ibr.cs.tu-bs.de (Stefan Petri)
To: amylaar@cs.tu-berlin.de, dack@darmstadt.gmd.de, mateese@ibr.cs.tu-bs.de,
        brenner@nova.tat.physik.uni-tuebingen.de
Subject: Returned mail: unknown mailer error 42

Hi!

On Tue, 9 Nov 1993 01:25:55 +0100 (MET),
MAILER-DAEMON@ibr.cs.tu-bs.de (Mail Delivery Subsystem) said:

Joern>  Sven Dack proposes to christen efun308() 'set_environment()' .

not too bad.

-------------------------------------------------------------------------------
Date: Sat, 13 Nov 1993 03:11:29 +0100 (MET)
From: amylaar@meolyon.hanse.de (Joern Rennecke)
Subject: LPmud Copyright
To: busey@ux1.cso.uiuc.edu (busey andrew), lars@cd.chalmers.se,
        croes@swi.psy.uva.nl, gusar@uniwa.uwa.OZ.AU, duening@ibr.cs.tu-bs.de,
        jacob@cd.chalmers.se, r_behren@informatik.uni-kl.de,
        mud@alijku05.edvz.uni-linz.ac.at, alcaman@cs.tu-berlin.de

Motivation of this letter:
There seems to be a potential for muds that run on dedicated machines
that charge fees from player to make the mud economically feasible.
The Copyright file says that LPmud can freely used iff it is not for
monetary gain. Now the debate what constitutes monetary gain and if
an individual license is an license to break the copyright,
is an interpretation of the license in Copyright or gives rights
independent the restrictions in Copyright has become a normal flame
war in the rec.games.mud.* groups. That is to say, one of the worst
thinkable.

To allow muds to charge fees to cover costs, without going through
such debates every time, I suggest to amend the Copyright file
with terms under witch such a mud is considered to comply to the
'no monetary gain clause' .

Explanation of the recipient list and some individual messages:

Busey Andrew: wants to set up a mud that charges fees to cover costs.
  If the below rules won't make it into the Copyright, you can regard this
  as a license - of course only for the code written by me.
Lars Pensj|: original author.
  Please forward this letter to other authors that have contributed to 3.1.2
  who have a say in the copyright.
Felix A. Croes: wrote the non-corrupting indentation code for ed.
Sean A Reith: wrote Mud-sprintf() .
Lars Duening: wrote the Amiga port.
Reimer Behrends: wrote mergesort based sort_array() .
Herp: wrote get_object_actions() .
Jacob Hallen: is one of the people involved with the CD driver; the email
 address was in the news recently...
  Please forward this letter to the person holding the copyright for the
  UDP connectivity(unless it's yourself :-) .
Alexander Weidt:
  Please try to forward this letter to my brother...

I hope to finally get terms which all autors can agree on that can be included
into the Copyright file. I suggest group replies, so that we can get some
kind of discussion going (unless there is immediate approval from all
authors :-) . When you have objections, please try to point out what is
wrong with these terms. Even better would it be if you had a solution
to the problem.

        Joern Rennecke (Amylaar)

Proposed Terms:
1. A LPmud may charge fees from players to cover running and machine costs.
2. Running costs in these terms are the cost for the network connection,
   electric power to operate the host machine, wear of backup media,
   repair costs for the host machine, and cost for a bank account.
   For the costs of a bank account to be considered runnung costs,
   they must not habe been considered according to 8. , and the
   institute has to be choosen with at least usual consideration on
   terms and costs of the account and that there must be no affiliaton
   with the institute.
3. Money to cover running costs for a maximum of 18 month may be accumulated
   in advance from fees to smoothe fluctation and to ensure stability of
   the mud. The spare money has to be kept separate from personal money
   and should be invested in trustee investment if liquidity allows.
   If the mud is permanently put down, this money has to be refounded to the
   playeres.
4. Machine costs are costs for buying, installation and upgrade of the host
   machine. The costs have to appear on a bona fide purchase / service
   contract with a person/institution that is not affiliated with the
   person who sets up the mud.
   When the host machine is put out of use, or parts of it are removed for
   other than technical reasons, are parts are nor re-inserted after the
   technical resons for removal and not re-inserting have become void,
   the current value of the machine that has put out of use/the removed
   parts is to be subtracted from the machine costs.
   If thus more money has been paid for machine costs than there are
   currently, the surplus amount has to be refounded to the mud players.
5. The machine cost share in the fee may not be more than 1/2400th
   of the machine costs per month. If the mud has less than 100 players,
   it may be up to machine costs / 24 / number of players, but not more than
   1/120th of the machine costs per month.
6. When money has to be payed back to the mud players, only those that
   have payed at least once a fee within the last 24 month are to be
   considered. For these players, the money is distributed in the ratio
   of the all fee shares ever payed to cover machine costs.
7. All players pay equal fees.
8. Banking costs that have to be paid by the mud administration and are
   immediately connected to incoming money transactions can be subtracted
   from the transferred amount before counting it as payment of fees,
   provided that the institute was choosen with at least usual
   consideration on terms and costs of the account, and that there is
   no affiliaton with the institute.
9. The amount of voluntary donations is unlimited. A donation is not
   considered voluntary if it is connected with special features or
   favours in the mud other than an hounarary mentioning of the donor,
   or if the donor is made to believe that such a connection exists.
   Reasonable measures have to be taken that there is no
   misunderstanding on this point.

Comments:
3. You may not use the money of the mud to bridge personal inliquidity.
   Don't gamble with other persons money, e.g. investing it in junk bonds.
5. Fees should not be arbitrarily raised so that players can be driven
   out. I considered a fixed minimal distributen of the costs to be
   the best means to codify this.
   Absolute figures are bound to become void by inflation.
6. The 24 month period is introduced to allow to erease records of
   clients after two years, and to keep overhead affordable.
7. We don't want favourites to get a free lift, and others grudgingly
   paying extra. If you think somebody needs free access, find someone
   who pays for it, or make a found payed from voluntary donations.

-------------------------------------------------------------------------------
Date: Fri, 19 Nov 1993 17:10:44 +0100 (MET)
From: Lars Pensj| <lars@cd.chalmers.se>
Subject: Re: LPmud Copyright
To: amylaar@meolyon.hanse.de (Joern Rennecke)
Cc: busey@ux1.cso.uiuc.edu, lars@cd.chalmers.se, croes@swi.psy.uva.nl,
        gusar@uniwa.uwa.OZ.AU, duening@ibr.cs.tu-bs.de, jacob@cd.chalmers.se,
        r_behren@informatik.uni-kl.de, mud@alijku05.edvz.uni-linz.ac.at,
        alcaman@cs.tu-berlin.de

I agree that fix of the copyright is needed. I would prefer to use the
Gnu Copyleft, as I don't care any longer if anyone makes money from it. The
important thing is that it is free, which means noone will be able to make
much money anyway.

Any thoughts about it ?

/Lars

-------------------------------------------------------------------------------
Date: Fri, 19 Nov 1993 20:14:10 +0100 (MET)
From: Jacob Hallen <jacob@cd.chalmers.se>
Subject: Re: LPmud Copyright
To: amylaar@meolyon.hanse.de (Joern Rennecke)
Cc: busey@ux1.cso.uiuc.edu, lars@cd.chalmers.se, croes@swi.psy.uva.nl,
        gusar@uniwa.uwa.OZ.AU, duening@ibr.cs.tu-bs.de, jacob@cd.chalmers.se,
        r_behren@informatik.uni-kl.de, mud@alijku05.edvz.uni-linz.ac.at,
        alcaman@cs.tu-berlin.de

> Jacob Hallen: is one of the people involved with the CD driver; the email
>  address was in the news recently...
>   Please forward this letter to the person holding the copyright for the
>   UDP connectivity(unless it's yourself :-) .

I represent everyone involved in the CD driver. The UDP stuff is to be
considered public domain. All other parts are covered by the non-profit clause.
Code origination from me, Johan Andersson (Commander), Ronny Wikh (Mrpr),
Lennart Augustsson (Marvin) is covered by it. We have no intention of
allowing people to charge money for the usage of our driver, or borrowed
pieces thereof.
We consider the acceptance of volontary donations as fair practice, and we
can accept the charging for the use of extra equipment needed to allow
people to access the mud, as long as there is a reasonable way to access the
mud without being charged. (Providing modem access at a cost while allowing
free access over the internet is an example of such a setup.)

My personal view is that an elaborate setup of terms like the one in the
original letter is unreasonable. It is designed for a very specific set of
circumstances. It is impossible to check and it is very bureaucratic.
It does not have my support.

Jacob Hallen

-------------------------------------------------------------------------------
Date: Sat, 20 Nov 1993 23:35:12 +0100 (MET)
From: Multi User Dungeon <mud@alijku05.edvz.uni-linz.ac.at>
Subject: Re: LPmud Copyright
To: lars@cd.chalmers.se (Lars Pensj|)
Cc: busey@ux1.cso.uiuc.edu, croes@swi.psy.uva.nl, gusar@uniwa.uwa.OZ.AU,
        duening@ibr.cs.tu-bs.de, jacob@cd.chalmers.se,
        r_behren@informatik.uni-kl.de, alcaman@cs.tu-berlin.de

Lars> important thing is that it is free, which means noone will be able to make
Lars> much money anyway.

You are speaking about the GD,correct ? Normally, many a site uses an unmodified
GD based upon which is a more or less heavily or not heavily Mudlib. Based upon
this Mudlib is the work of the `wizards' ... Sorry for repeating known stuff.

This makes most Muds differ from each other. So, the fact that the GD itself
is free, doesn't imply that you won't make money.

Another point to argue: maintainig a Mud takes time .. a LOT of time. Usually,
doing so is not fun at all. I experienced that the more players you have, the
less fun it is fore the adminstrators. You spend a lot of time coding,
searching and fixing bugs ... and I think, this can be regarded as a
service for players (... and players really can be a pain sometimes ...)
Would it be legal to charge money for that ?

Another thought: Internet Muds. They run on internet, usually on computers
owned by a school or university, some with, some without the knowledge of
the site adminstrators. Would it be legal to charge money when you run
a Mud on equipment not owned by yourself ? And, even if you own the computer,
do you pay for the internet link ? If not, I fear you must not charge money
for a Mud without speaking with the network adminstrator since you are using
the network components (router/bridges, even cables :-> ...) for free.

How difficult is charging money in European Muds ? Not that I plan
to do so for HM (it's closed for players currently anyway), but isn't there a
big difference according to the "accounting mechanism" (ugh, bad english :-)
that is used in the States ? I heard that it is much more easy to make
financial transactions within the States. So, I suspect the "Mud money charging"
discussion arrives from the US :-)

Greetings, Herp (mud@mud.uni-linz.ac.at)

------------------------------------------------------------------------------
