Subject: Re: LambdaCORE referance

From: [email-masked] (Michael Richardson)
Date: Sun, 17 Jan 1993 19:36:18 -0800

On Jan 17,  6:59pm, Pavel Curtis wrote:
} >        I was wondering if anyone would be interested in providing
} >     information or assistance in writing a new LambdaCORE reference.
} 
} I think that the Right Thing would be for any new Core documentation to reside
} *inside* the LambdaMOO database, so that it could most easily be updated
} whenever changes are made to the Core code and then automatically extracted
} along with the rest of LambdaCore.db whenever that happens.

  I was hacking around a week ago with some MOO and Emacs code to
convert Frand-style manuals to Info mode. I got stuck somewhere
converting ^_ to the actual control character. I think I might convert
to texinfo stuff instead, but I was hoping to do some magic with
buffer that I got and turn on Info-mode. It isn't that easy, so
running tex2info isn't such a problem I guess.
  If you will remember, I info-ized the first Moo Programming Language
reference, and wished it had been kept in that format rather than just
produce pretty ascii.

} If anyone finds something that isn't well enough documented in the Core (and
} you won't have far to look...), then feel free to write something up about it
} and send it to *Wizards on LambdaMOO.  One of us will add it into the help
} system in an appropriate place and then everyone can enjoy it.

  I didn't clue in at first as to what the Museum was all about until
I visited it today. That is a very good thing to have! All those
usefull objects in one ``place''. (I don't think their location is
necessarily in the museum)

-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: [email-masked]     Bell: (613) 237-5629
SCHOOL: [email-masked]

---

From: Quinn Avery <[email-masked]>
Date: Fri, 15 Oct 1993 14:11:20 -0700

break    (break outta current loop)
continue (continue to next iteration of current loop)
 
Wouldn't be too hard to add, would they?  Are there stylistic
 programmer objections to these kinds of statements?
 
Also... Any word on if the following (previously discussed) will
 be included in any upcoming versions?
 
list[2..]
last(list)
any(list)
 
-quinn

---

From: Pavel Curtis <[email-masked]>
Date: Fri, 15 Oct 1993 17:17:34 -0700

> Date:	Fri, 15 Oct 1993 14:11:20 -0700
> From:	Quinn Avery <[email-masked]>
>  

I will be adding these, but with an optional identifier following the keyword,
identifying the loop involved.  For FOR loops, the loop name is the name of the
loop variable (i.e., the `x' in FOR x IN ...) and for WHILE loops, an optional
identifier can appear between WHILE and the open parenthesis.

Thus, in the following code:

	for x in (some_list)
	  while y (some_condition)
	    ...
	    break x;	/* 1 */
	    ...
	    break y;    /* 2 */
	    ...
	  endwhile
	endfor

statement (1) terminates the outer loop, and statement (2) terminates the inner
one.  If no identifier appears in a BREAK or CONTINUE statement, it is assumed
to refer to the innermost enclosing loop, just like in C.

> any(list)

These would be written as follows in 1.8.0, according to current plan:

	Quinn		Current MOO		New MOO
	-----		-----------		-------
	x[2..]		x[2..length(x)]		x[2..$]
	last(x)		x[length(x)]		x[$]
	last(x)		x[random(length(x))]	x[random($)]

Essentially, the subscripting bracket will define a pseudo-variable, $, whose
value is the length of the value being subscripted.  You can use that pseudo-
variable in any (enclosed) expression context.  So, to extract the last two
elements of a list (presumed to contain at least two elements), you'd say

		x[$ - 1 .. $]

Just for Rog, here's my favorite gross hack with this new syntactic feature:

		x[len = $];

This statement is more concise way to say this now old-fashioned statement:

		len = length(x);

Comments?

	Pavel

---

From: Greg Hudson <[email-masked]>
Date: Fri, 15 Oct 1993 17:48:52 -0700

> This statement is more concise way to say this now old-fashioned

More concise, perhaps, but at least I know what the second statement
does at a glance.

Congratulations on reinventing Perl.

I really despise magic variables, especially ones that get initialized
in the middle of your code with no explicit statement to the reader
that anything has happened.

I also don't terribly like how the list[foo..bar] notation handles
boundary cases; for instance, list[2..length(list)] reliably gets "all
the elements but the first", but only because MOO makes an exception
for "a sublist starting one element past the end of the list".  Thus
{0}[2] is invalid, but {0}[2..1] is fine.  Go figure.

In Coldmud, I provide a function sublist(list, start, len) where the
third argument is optional and defaults to (length(list) - start + 1).
The exceptions are now (len < 0) or (start + len - 1 > length(list)),
and there's no confusion between sublisting and indexing and their
error conditions.

--GBH
Feeling militantly minimal

---

From: Roger Crew <[email-masked]>
Date: Fri, 15 Oct 1993 19:35:04 -0700

>   Just for Rog, here's my favorite gross hack with this new

[Rog LOL].  That's really sick.

I'm sufficiently happy about the other stuff that I might even promise
never to use this (an easy promise to keep, given the amount of MOO
coding I do these days; ...but...but... it saves an entire tick!
... must think carefully about this...).

>   Essentially, the subscripting bracket will define a pseudo-variable, 
>   $, whose value is the length of the value being subscripted.

This should include subscripting brackets that appear in FOR statements,
e.g.,

   FOR i in [5..$]
   ...

is a loop starting at 5 that runs forever.

In this case, the value being subscripted is simply {1,2,3,... }
(i.e., all natural numbers).  With this in mind, $ is clearly
+infinity, though 2^32-1 will do for those of us who have to live in
the real world.  I suggest this mainly for consistency's sake, though
there have been a few occasions where being able to do this would have
come in handy (yes, you can write WHILE (1) ... i=i+1 ENDWHILE, but
then you can write *any* FOR loop as a WHILE, and if you forget to put
in the i=i+1, you lose...).

For real hack value, LambdaCore could include the following code in its
$server_started()

   FOR i in [1..$maxint=$]
     BREAK;
   ENDFOR

to set $maxint appropriately for the machine architecture.

	Roger  (militant orthogonalist...)

---

From: Pavel Curtis <[email-masked]>
Date: Sat, 16 Oct 1993 15:24:39 -0700

> Date:	Fri, 15 Oct 1993 17:48:52 -0700
> From:	Greg Hudson <[email-masked]>
> 
> >		x[len = $];

It would appear that I was insufficiently clearly tongue-in-cheek here; I
apologize.  I do not recommend the writing of such code, of course.

> that anything has happened.

Um, I think it's pretty easily understandable as a part of the [] notation for
subscripting.

> {0}[2] is invalid, but {0}[2..1] is fine.  Go figure.

This is not true.  There is no exception for any boundary cases; rather, there
is a simple rule.  In the expression `x[m..n]', if m > n then the result is the
empty list or string (depending upon the type of x).  If m <= n, then both must
be in the range [1..length(x)] and the obvious subsequence is extracted.

> and there's no confusion between sublisting and indexing and their

I don't see where there's any confusion in MOO over these facilities, either.
I assume in Coldmud that you provide a convenient syntax for indexing, rather
than another function index(list, n), right?  We are simply providing such a
concise and readable syntax for another very common operation: subsequence
extraction.

	Pavel

---

From: [email-masked]
Date: Mon, 18 Oct 1993 11:55:12 -0700

>>identifying the loop involved.
>>
>>Comments?

My comment is that it sure sounds a lot like BCPL.  Let's take C
backwards in time! (Just kidding.)

Actually I've always missed these constructs in C and I'm glad to see
them contemplated here.

Mike O'Brien

---

From: [email-masked]
Date: Tue, 26 Oct 1993 21:01:06 -0700

As a Wizard on OpalMOO, I've run into the problem that a particular
 problematic player's registered email address is not valid.  When
 I run @@who on him, his connect site is completely different from
 his email site.  In fact, his connect site is the OpalMOO site itself
 so I _can't_ lock out his site.  But how can I find out just
 what account he's connection from?  I want to notify the higher
 up sysadmins that he's abusing his access.  Is it possible to trace
 the player back any farther than @@who gives you?

--- Dov Sherman
    [email-masked]

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 27 Oct 1993 10:32:40 -0700

> Date:	Tue, 26 Oct 1993 21:01:06 -0700
> From:	[email-masked]
>  
>  But how can I find out just what account he's connection from?  I want to
>  notify the higher up sysadmins that he's abusing his access.  Is it possible
>  to trace the player back any farther than @@who gives you?

Yes, but not reliably or in general.  The underlying network protocols do not
provide the information you want to know and, lacking any global authentication
system, they really can't in general.  What you can sometimes do is to `finger'
the site they're connecting from and see if there's either only one person
logged in or else only one person unidle.  Alternatively, if you've got an
account on the machine they're connecting from, you could employ such commands
as netstat and lsof (list open files) to try to determine exactly what UNIX
process the packets are coming from and, thus, who's running the command.  If
you're not using UNIX, congratulations, but you'll have to figure out the
equivalents yourself.

Of course, you can always @newt or @toad the offending MOO player and thus keep
them from connecting to it.  You might also consider @blacklist-ing the local
site, which only keeps them from connecting as Guest.

	Pavel

---

From: [email-masked]
Date: Wed, 27 Oct 1993 11:57:35 -0700

Here's my take on the problem, expanding on what Pavel said.
While it's true that global authentication is a wish-list item for the
Internet, let's face it, most people connecting to a MOO are not up
to spoofing Internet addresses.  If you take that as a given, there are
several things you can do, which vary depending on the situation.

	Situation 1) There is only one person from the offending site
currently connected to the MOO, and you have access to the offending
site (or can get it temporarily).  In that case you can do things
pretty much straight up.  Use 'netstat' or the moral equivalent to find
the process connected to your MOO, and see who owns that process.
You've got it.

	Situation 2) There are several people from the offending site
connected to the MOO at all times, so you can't isolate the user,
but you do have access to the foreign site (or can get it).
This gets trickier.  You must convince the MOO to tell you the foreign
port number associated with the offending player.  I don't think this is
in the current server (I haven't dug that deep so I could be wrong),
which would mean some server hacking.  Then you go to the foreign
site and use 'netstat' or the moral equivalent thereof to determine
which process owns that particular port number.  You've got him.

	Situation 3) There is only one user from the offending site
connected to your MOO, but you don't have access to that site.
In that case, you get to play a statistical waiting game.  Set up
a shell script to finger the site every half hour, and take an @@who
listing at the same time.  Correlate who's logged on at the foreign site,
with the times the offending player is on the MOO.  If the foreign site
doesn't support 'finger' protocol you're out of luck.

	Situation 4) There are always multiple users from the offending
site connected to your MOO, and you don't have access to that site.
Technically speaking you're out of luck.  At this point you have to
prove how good a wizard you really are by using people skills instead
of technical skills, to either convince the offender not to be anti-social,
or to convince one of the other players at that site to reveal the
offender's identity.

	In fact the longest-running MUD on the Internet reverses these
priorities, and uses technical means of detection only as a last resort.
In all the years that MUD's been up, this has only been necessary on
a very few occasions.  Since the MUD doesn't run with player registration,
it's really the only practical alternative: if a @toaded player can
immediately create a new character, @toad loses its force, and knowing
a player's true identity is no bar to the creation of a new character.
Long talks and moral suasion have been successful there, where they
have apparently failed on LambdaMOO.

Mike O'Brien

---

From: [email-masked]
Date: Sun, 14 Nov 1993 17:24:32 -0800

> 	Quinn		Current MOO		New MOO

Yes.  I prefer the Icon model, in which integers refer to positions
between elements of a list.  Positive integers number positions from
left to right; nonpositive from right to left.  Here's an examplle:

		your	mama	wears	army	boots
	    1        2        3       4       5       6
           -5       -4       -3      -2      -1       0

So to grab all but the last element it's l[1..-1] (actually Icon uses a
colon instead of .. but that's irrelevant).  Naming a single position
gets you the element to the right; so the first element is l[1], the
last is l[-1], and so on.  FYI, Icon has a few other nice list and
string manipulators that could be worth considering for the MOO.

Norman

---

From: [email-masked]
Date: Sun, 14 Nov 1993 22:18:00 -0800

Date: Sun, 14 Nov 1993 20:24 EST
    From: [email-masked]

    ... I prefer the Icon model, in which integers refer to positions
    between elements of a list.  Positive integers number positions from
    left to right; nonpositive from right to left. ... the last is l[-1]
    ...

This has the problem that arithmetic errors that erroneously lead to
negative numbers will not be detected because it has a well-defined
meaning.  A good property for a language syntax to have is to be sparse
enough that readily anticipatable errors will tend to be detected.  I
think the new $ syntax has this property and your negative subscripts
syntax does not.
 -kmp