INFO
lpc standard - a beast in progress?
DESCRIPTION
This is a rather long and incoherent list of mail to a mailing list.
It's a lot of talk, and not much said. It shows that at least some
people think it could be possible to make a LPC standard. The document
is _not_ formatted.
From borg@nightmare.imaginary.com Mon Jan 16 18:32:52 1995
From: borg@nightmare.imaginary.com (George Reese)
Subject: Re: LPC (again :)
To: lpc-language@nightmare.imaginary.com
Date: Mon, 16 Jan 1995 18:19:13 -0600 (CST)
Reimer Behrends once wrote...
>
> Hmm. I do not quite see what operator overloading has to do with
> object-orientedness. After all, you can always write a->plus(b) or some
> such stuff. Seems to be more a syntactic thing (From C++ experience I
> also think that it can lead to messy code - the meaning of an operator
> can be quite unobvious). Also, polymorphism in several variables can lead
> to nasty type problems.
>
> Reimer Behrends
Well, the idea behind overloading is that you define operators where
the behaviour of the operators is self-evident. One example is what I
was saying about messaging. #1 there should be some sort of operator
like << (not bitwise shift :)). And I think you would expect it to
behave in certain ways for sockets as opposed to users as opposed to
monsters. If the meaning of the operator is not obvious, then it
should not be overloaded.
--
George Reese (borg@imaginary.com) http://www.winternet.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From borg@nightmare.imaginary.com Mon Jan 16 18:42:43 1995
From: borg@nightmare.imaginary.com (George Reese)
Subject: Re: LPC & OOPL
To: lpc-language@nightmare.imaginary.com
Date: Mon, 16 Jan 1995 18:09:40 -0600 (CST)
DGD/KCJ Development once wrote...
>
> Another change which I made (a very tiny one) is that calling a non-existant
> function or a static function by means of a call_other() is a runtime error,
> rather than returning 0. I don't understand why Lars ever decided to return
> 0 on those calls, because it causes a lot of difficulties when trying to locate
> a bug. Perhaps it's a result of the history of LPC, where inheritance was
> not in the first version. The many muds around show that one can work with
> the existing way very well, and as a mud-programmer I'm very used to it, and
> really have no problem with it. It's convenient at times. But for a language
> which will be presented to beginning programmers, I think it's an aspect which
> one should try to get rid of, if possible. Since I didn't have to depend on
> anything for my thesis, I was free to drop the 'return 0' version completely.
>
IMHO, this is a totally non-OO way to do things. You cannot look at
the call other as a simple calling of a function in another object.
It is actually the triggering of an event in the foreign object, to
which the object may or may not decide to respond. In objects where
no such event is defined, the behavious should be to do nothing.
--
George Reese (borg@imaginary.com) http://www.winternet.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From aedil@linux.cc.kuleuven.ac.be Mon Jan 16 19:30:53 1995
From: DGD/KCJ Development
Subject: Re: LPC & OOPL
To: lpc-language@nightmare.imaginary.com
Date: Tue, 17 Jan 1995 02:15:36 +0100 (MET)
George Reese mailed me:
>
> DGD/KCJ Development once wrote...
> >
> > Another change which I made (a very tiny one) is that calling a non-existant
> > function or a static function by means of a call_other() is a runtime error,
> rather than returning 0.
>
> IMHO, this is a totally non-OO way to do things. You cannot look at
> the call other as a simple calling of a function in another object.
> It is actually the triggering of an event in the foreign object, to
> which the object may or may not decide to respond. In objects where
> no such event is defined, the behavious should be to do nothing.
I disagree quite strongly on this. Although I phrase it as calling a function,
that does not mean that it cannot be read as synonym for 'calling a method' or
'sending a message'. In programming one ought at least to be able to expect to
know what one is doing, and hence calling a function/method/event in another
object assumes that you know that function/method/event exists. If it doesn't,
then you shouldn't be calling it.
Inheritance solves a thing like this easily by defining a function which will
version of it. But just not doing anything is hardly acceptable since *that*
is actually something that could also take place when the function/method/event
*does* exist. And thus it creates a duality in the language, as you can't be
be certain whether a call returns 0 because that is the actual result, or as
a result of the function being unreachable (static) or non-existant.
Also, returning 0 makes the assumption that 0 is the 'default' value you want
if the function does not exist. Once this is known, it's not too difficult
to work with it, as I explained in my previous posting. But that's just a
result of not having any choice. We're kind of stuck with drivers and LPC in
which this behaviour has been accepted. But I don't agree at all that you
can defend it as being more OO.
Kris.
From tim@handel.Princeton.EDU Mon Jan 16 20:41:49 1995
From: tim@handel.Princeton.EDU (Tim Hollebeek)
Subject: Re: LPC (again :)
To: lpc-language@imaginary.com
Date: Mon, 16 Jan 95 21:30:06 EST
George Reese writes ...
> From borg@nightmare.imaginary.com Mon Jan 16 13:23:53 1995
> Message-Id:
> From: borg@nightmare.imaginary.com (George Reese)
> Subject: Re: LPC (again :)
> To: lpc-language@nightmare.imaginary.com
> Date: Mon, 16 Jan 1995 12:17:23 -0600 (CST)
> Reply-To: lpc-language@imaginary.com
> In-Reply-To: <199501160613.HAA22639@linux4.cc.kuleuven.ac.be> from "DGD/KCJ Development" at Jan 16, 95 07:13:14 am
> X-Mailer: ELM [version 2.4 PL23]
> Content-Type: text
> Content-Length: 2504
>
> DGD/KCJ Development once wrote...
> > class. All "objects" inherit automatically from that class (as it is actually
> > implemented in DGD). This is definitely a good start for an OOPL. You did
> > mention inheritance already, and fact that it is multiple inheritance pleases
> > me even more.
> >
>
> I definitely think multiple inheritance is a bonus for LPC. I also
> think that the DGD auto-object paradigm is cool too. This does not
> really address the problems I mentioned though. Once example would be
> operator overloading. I think you need to be able to define in some
> way operator overloading (which an auto-inherit object would
> definitely help do). Even in DGD with an auto-inherit object, you
> cannot redefine + for a new class. In fact, in all current LPC
> implementations, creating a "class" where a class != a file is kludgy.
>
MudOS will have user overloadable operators over my dead body :)
90% of the time, overloading + is some cute syntax that would be better
done with a well named member function.
-Beek
From owner-lpc-language@nightmare.imaginary.com Mon Jan 16 12:38:47 1995
Date: Mon, 16 Jan 95 12:30 CST
To: earendil@orion.etsu.edu
From: majordomo@nightmare.imaginary.com
Subject: Welcome to lpc-language
Welcome to the lpc-language mailing list!
If you ever want to remove yourself from this mailing list,
you can send mail to "majordomo@nightmare.imaginary.com" with the following command
in the body of your email message:
unsubscribe lpc-language Earendil the Mariner
Here's the general information for the list you've
subscribed to, in case you don't already have it:
LPC Language Mailing List
This mailing lists exists for the sake of promoting discussion on the
LPC programming language and its development. Discussion about all
uses of LPC from games to business is encouraged here.
From borg@imaginary.com Mon Aug 21 09:42:06 1995
Date: Mon, 21 Aug 1995 09:06:50 -0500
Posted-Date: Mon, 21 Aug 1995 09:06:50 -0500
To: lpc-language@imaginary.com
From: borg@imaginary.com (George Reese)
Subject: Spec for LPC
As some of you may know, I am working on a base spec for the LPC language.
I am interested in capturing the base commonalities, not in creating
barriers. If there are any areas of conflict, I would like to see them
discussed here. My in progress draft is at
http://www.imaginary.com/LPC/spec.html. Please remember, it is a work in
progress and it is a draft. There are certain to be errors and omissions
and controversies. If nothing else, I would like to see Beek, Dworkin, and
Amylaar buy off on this before it is *done* (knowing of course that it never
ever should be done).
--
George Reese (borg@imaginary.com) http://www.imaginary.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From borg@winternet.com Mon Aug 21 10:49:45 1995
From: George Reese
Posted-Date: Mon, 21 Aug 1995 10:26:36 -0500
Subject: Re: Spec for LPC
To: lpc-language@imaginary.com
Date: Mon, 21 Aug 1995 10:26:36 -0500 (CDT)
In-Reply-To: <199508211445.QAA21706@linux4.cc.kuleuven.ac.be> from "Kris Van Hees" at Aug 21, 95 04:45:04 pm
Kris Van Hees once wrote...
>
> This is certainly a good idea, and I hope the base sepc will include appendices
> pointing out in what way specific implementations differ from the
base spec.
Definitely. Right now I am noting where I know different
implementations occur. I hope later once the foundation is agreed
upon, I can go back and elaborate on those differences. This will,
of course, require ongoing input from people maintaining their own
dialects.
> I
> could add here also that my thesis implementation is based on DGD but with a
> different LPC dialect so to speak. It mainly has to do with object oriented
> ideas, and flexibility in object world compared to filesystem (differentiating
> object naming with pathnames, making movement of code irrelevant for the
> working of the mud, which is a major convenience since it takes away the need
> for header files (.h) or changing every single file with a reference to it.
I believe LPC's strength is in its diversity. First off, I do not
think there is a single bad implementation being commonly used right
now. I think that DGD, MudOS, and LPMud 3.2.* are all very good
drivers and people can come away a winner using any one of the above
unless they have really narrowly defined requirements (i.e. if you
absolutely must have closures, then that kinda narrows your choices).
I believe that each of these implementations have helped to make the
others better. So I suppose what I am trying to say is that I think
it only beneficial to have new ideas and new implementations.
--
George Reese (borg@imaginary.com) http://www.winternet.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From nobody@nightmare.imaginary.com Mon Aug 21 11:04:49 1995
Sender: nobody@nightmare.imaginary.com
Date: Mon, 21 Aug 1995 09:06:50 -0500
Posted-Date: Mon, 21 Aug 1995 09:06:50 -0500
To: lpc-language@imaginary.com
From: borg@imaginary.com (George Reese)
Subject: Spec for LPC
As some of you may know, I am working on a base spec for the LPC language.
I am interested in capturing the base commonalities, not in creating
barriers. If there are any areas of conflict, I would like to see them
discussed here. My in progress draft is at
http://www.imaginary.com/LPC/spec.html. Please remember, it is a work in
progress and it is a draft. There are certain to be errors and omissions
and controversies. If nothing else, I would like to see Beek, Dworkin, and
Amylaar buy off on this before it is *done* (knowing of course that it never
ever should be done).
--
George Reese (borg@imaginary.com) http://www.imaginary.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From nobody@nightmare.imaginary.com Mon Aug 21 11:41:28 1995
Sender: nobody@nightmare.imaginary.com
From: George Reese
Posted-Date: Mon, 21 Aug 1995 11:12:04 -0500
Subject: this list
To: lpc-language@imaginary.com
Date: Mon, 21 Aug 1995 11:12:04 -0500 (CDT)
I have done the same thing to this as was done with intermud, namely
the list is getting filtered so that Reply-To is set to the list and
not the author and errors are getting sent off to /dev/null.
--
George Reese (borg@imaginary.com) http://www.winternet.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From nobody@nightmare.imaginary.com Mon Aug 21 11:59:35 1995
Sender: nobody@nightmare.imaginary.com
From: George Reese
Posted-Date: Mon, 21 Aug 1995 10:26:36 -0500
Subject: Re: Spec for LPC
To: lpc-language@imaginary.com
Date: Mon, 21 Aug 1995 10:26:36 -0500 (CDT)
In-Reply-To: <199508211445.QAA21706@linux4.cc.kuleuven.ac.be> from "Kris Van Hees" at Aug 21, 95 04:45:04 pm
Kris Van Hees once wrote...
>
> This is certainly a good idea, and I hope the base sepc will include appendices
> pointing out in what way specific implementations differ from the
base spec.
Definitely. Right now I am noting where I know different
implementations occur. I hope later once the foundation is agreed
upon, I can go back and elaborate on those differences. This will,
of course, require ongoing input from people maintaining their own
dialects.
> I
> could add here also that my thesis implementation is based on DGD but with a
> different LPC dialect so to speak. It mainly has to do with object oriented
> ideas, and flexibility in object world compared to filesystem (differentiating
> object naming with pathnames, making movement of code irrelevant for the
> working of the mud, which is a major convenience since it takes away the need
> for header files (.h) or changing every single file with a reference to it.
I believe LPC's strength is in its diversity. First off, I do not
think there is a single bad implementation being commonly used right
now. I think that DGD, MudOS, and LPMud 3.2.* are all very good
drivers and people can come away a winner using any one of the above
unless they have really narrowly defined requirements (i.e. if you
absolutely must have closures, then that kinda narrows your choices).
I believe that each of these implementations have helped to make the
others better. So I suppose what I am trying to say is that I think
it only beneficial to have new ideas and new implementations.
--
George Reese (borg@imaginary.com) http://www.winternet.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From nobody@nightmare.imaginary.com Mon Aug 21 14:05:34 1995
Sender: nobody@nightmare.imaginary.com
From: George Reese
Posted-Date: Mon, 21 Aug 1995 13:31:51 -0500
Subject: Re: Spec for LPC
To: lpc-language@imaginary.com
Date: Mon, 21 Aug 1995 13:31:50 -0500 (CDT)
In-Reply-To: <199508211628.AA23836@xs1.xs4all.nl> from "Richard Braakman" at Aug 21, 95 06:28:21 pm
Thanks for some really good comments. I wanted to comment on a few of
those comments though...
Richard Braakman once wrote...
> > This text attempts to define a core set of behaviours for LPC. Taken
> > to an extreme, such an attempt can serve to destroy the open
> > development which has made LPC as successful as it has become.
>
> Actually, I doubt any single document could have that effect.
>
If people paid any attention to it, it could. I suppose what I am
trying to say is that I do not want to get into a situation where
anyone is saying things like "DGD is really LPC, but LPMud 3.2 is
not." So perhaps I have mis-worded the above, especially since any
such document would hopefully be ignored by people.
>
> Catch and sscanf have been reserved since 3.1.2; is there
> any driver which doesn't reserve them?
>
Well, not to my knowledge. However, it seems to me that sscanf()
particularly as a reserved word is more of an accident than something
that should be considered integral to the language.
Perhaps I am wrong on this though... Any comments?
> I don't remember any driver reserving "throw", and I don't
> know why a driver would have to.
>
MudOS will be implementing some sort of exception handling beyond
catch() and error(). This set of "sometimes keywords" included what
little I knew about Beek's plans.
> > The
> > same escape sequences which exist for characters also exist for
> > strings, excepting \' and including \" for double quotes.
>
> This distinction is probably irrelevant, since \' and \" behave
> the same way in either character constants or string literals.
>
The distinction is important, because if you have warnings on, MudOS
will generate a warning on it (it still works properly, however).
> > 2.5.4 Mapping Constants
> >
> > Mapping lists are enclosed in ([ ]) with individual list items, each
> > item separated by a comma. Within each item of the list, the key/value
> > pairs are separated by a colon. No whitespace is required within the
> > ([]). Individual key or value values may be made up of variables or
> > constants. Any values within the mapping constant which are
> > represented by a variable take on the value of the variable of that
> > time. For non-pointer data types, this value will fail to reflect any
> > further changes to the state of that variable. For implementations
> > with functionals, the functionals variables behave within a mapping
> > constant like the non-pointer data types (they are copied).
>
> It sounds like you need to distinguish between mapping constants and
> mapping aggregation expressions. Alternately, it may be preferable
> to list them both as expressions.
Yeah, i have been toying with this in my mind and am not at all
convinced I am handling this section the right way for a language definition
spec. Your comment only adds to my doubts. I really don't quite know
how to handle this right now.
> In DGD at least, x = y = ([])
> is different from x = ([]); y = ([]), which indicates that even
> empty mappings behave as expressions.
> (Similarly, ({}) != ({})).
>
> This point is unrelated to their emptiness: ({ 1 }) != ({ 1 }).
> (For all implementations, I would guess.)
>
In MudOS, ({}) == ({}), but ({ 1 }) != ({ 1 }). Basically, all empty
arrays and mappings point to the same empty mapping/array object (I
think). I also think this is a relatively new feature. But I could
be completely wrong here.
> > Storage of Mappings
> >
> > The deallocation of mapping values is undefined, as the existence of
> > NULL and undefined are not standardized. Thus in some implementations,
> > setting a mapping member to 0 may be sufficient, whereas in others
> > that represents holding a value under that key.
>
> I don't understand this. Perhaps you mean "the technique for removing
> a key and value pair from a mapping is undefined".
> Deallocation of mapping values is done with map[key] = 0; removing
> the index is another matter.
>
>
My goal in the quoted text is to demonstrate that:
DGD: m["x"] = 0
is the same as
MudOS: map_delete(m, "x");
is the same as:
LPMud: m = m_delete(m, "x");
Could I have done a better job at wording that perhaps?
You also stated a couple of things with respect to LPMud 3.1.2...
> 3.1.2 reserved "protected" for no particular reason.
> Oh, and "unknown", which was a type that required a cast.
>
AND...
> 3.1.2 had an error which was never fixed:
> func() {
> { int foo;
> foo = 1;
> }
> { int foo;
> return foo;
> }
> }
>
> This would return 1.
>
The approach I am currently taking is to worry about current
implementations (DGD, MudOS, LPMud 3.2.1, LPMud 3.2) as well as
planned implementations (Sima and Aedel's thesis). Just because the
spec says something that is not true in an old, non-evolving version
of LPC does not suddenly render it not LPC. It just makes it what it
is, pre-spec LPC. The spec should get a picture of what LPC is like
today and in what direction it is going. And perhaps someday some
things will be added to it that no current driver supports. Do you
disagree with this approach?
--
George Reese (borg@imaginary.com) http://www.winternet.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From nobody@nightmare.imaginary.com Mon Aug 21 14:09:05 1995
Sender: nobody@nightmare.imaginary.com
Date: Mon, 21 Aug 1995 11:44:23 -0700 (PDT)
From: Greg Stein
Subject: Re: Spec for LPC
To: lpc-language@imaginary.com
In-Reply-To: <199508211406.JAA21340@icicle>
If you are not interested in legislating LPC, but merely documenting it,
then I would suggest a couple things:
1) don't call it a spec. Call it documentation or a description. LPC Spec
seems to imply that you are specifying the LPC language rather than
describing existing implementations. This may be just how I read it,
though.
2) never use the word "standard" or "non-standard." I saw a reference in
the document to a "non-standard keywords." That is simply not the case,
since there is no standard, by your own definition. Calling something
non-standard implies the existence of a measure of conformance and
regulation.
And one edit nit for you :-)... the "arrays" link at the start of section
3 is invalid.
The document is a good start. I'll warn you, though, it could get
awfully long :-). I have a feeling that you may run into a need to
document program loading and cloning and stuff... *shiver* Maybe you can
avoid it with a "this is a syntactical description but does not cover
operational behaviors" hehe
cheers...
-Deathblade
--
Greg Stein (gstein@svpal.org) #include
From nobody@nightmare.imaginary.com Mon Aug 21 14:16:03 1995
Sender: nobody@nightmare.imaginary.com
From: George Reese
Posted-Date: Mon, 21 Aug 1995 13:45:58 -0500
Subject: Some notes on various implementations
To: lpc-language@imaginary.com
Date: Mon, 21 Aug 1995 13:45:57 -0500 (CDT)
In-Reply-To: <199508211628.AA23836@xs1.xs4all.nl> from "Richard Braakman" at Aug 21, 95 06:28:21 pm
One thing I had hoped for this to bring out were various trivial
differences among the different implementations as well as to lead to
some inter-driver discussion. Dark brought up a couple of things I
felt fell into this category.
This is in a separate subject thread from the LPC spec specifically
because the spec is being written for LPC as it is. This letter is to
talk about the way it ought to be.
Richard Braakman once wrote...
> > The characters /* at any point in the input stream represent the
> > beginning of a comment. The comment is considered to continue until
> > the next occurrence of the characters */. Some implementations may
> > allow nesting of comments, but this specification neither mandates nor
> > prohibits such behaviour.
>
> /\
> * comment *\
> /
> will be parsed as a comment in DGD. Perhaps you need to define
> the translation phases more precisely. (ANSI C89 has seven!)
>
I am curious if this is legal in other drivers? Why isn't it if it is
not?
> > The characters // also mark the beginning of a comment. Comments begun
> > with those characters continue until the end of the line on which they
> > occur. // characters placed within a comment are treated simply as
> > part of the greater comment in which they exist.
>
> DGD does not have // comments.
>
Why not? They are quite useful at times, especially if you are using
an editor capable of easily generating and deleting such comments.
> > 2.5.1 Integer Constants
> >
> > Integer constants may be expressed in octal, decimal, hexidecimal, or
> > as their character counterpart as specified by the ASCII standard.
> > Octal constants are digits beginning with a 0 (digit zero) and
> > consisting of only the digits 0-7. An integer constant consisting
> > solely of the digits 0-9, but not starting with the digit 0, is
> > considered a decimal. Hexidecimal constants begin with 0x and consist
> > of the digits 0-9 as well as the letters a-f or A-F. Characters are
> > surrounded by single quotes.
>
> DGD only recognises decimal integer constants in all contexts. Octal
> integer constants are recognised as characters and in strings.
>
I would think that recognizing hexadecimal constants should be a
feature, especially where bitwise operations may be needed.
> >
> > A floating point constant consists of an integer part, a decimal
> > point, and a fractional part. The integer and fractional parts both
> > consist of a sequence of digits. Neither the fractional nor the
> > integer parts may be missing. Values less than 1 may have the integer
> > part as 0. Similarly, floats with no fractional part should have the
> > fractional part shown as 0.
>
> DGD recognises 1. as a floating point constant. I believe this is
> because ANSI C also recognises it.
>
I put this in this way because I know MudOS does not allow 1, however,
I would think MudOS should (does LPMud?). In other words, I would
like to see LPC done the way DGD and ANSI C do it.
> > 2.5.3 String Constants
> >
> > A string constant, also called a string literal, is a sequence of
> > characters surrounded by double quotes. Since the internal
> > representation of a string may vary from implementation to
> > implementation, the existence of a null terminator is not defined.
> > Some implementations may handle non-null terminated strings (binary
> > data) in alternate fashions.
> >
> > Adjacent string constants are concatenated into a single string.
>
> DGD does not do this.
>
This is ANSI C. Any reason why DGD does not do it?
> > 4.1 CASTING
> >
> > With respect to a core definition of LPC, casting is syntactic sugar
> > with no meaning. However, some implementations may require casting in
> > ambiguous situations, such as with calls to functions in external
> > objects and classes. Casting does not, however, perform any data type
> > conversions.
>
> DGD's casts do perform data type conversions among string, float, and int.
>
I like the DGD way of doing this :)
--
George Reese (borg@imaginary.com) http://www.winternet.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From nobody@nightmare.imaginary.com Mon Aug 21 20:42:54 1995
Sender: nobody@nightmare.imaginary.com
To: lpc-language@imaginary.com
Subject: Re: Some notes on various implementations
In-Reply-To: Your message of "Mon, 21 Aug 1995 13:45:57 CDT."
Date: Mon, 21 Aug 1995 15:59:25 -0400
From: Robert Leslie
>> DGD does not have // comments.
>
> Why not? They are quite useful at times, especially if you are using
> an editor capable of easily generating and deleting such comments.
While I have no interest in fueling a style debate on the use of // comments,
they are not implemented in DGD because Dworkin doesn't want them.
>> DGD only recognises decimal integer constants in all contexts. Octal
>> integer constants are recognised as characters and in strings.
>
> I would think that recognizing hexadecimal constants should be a
> feature, especially where bitwise operations may be needed.
In fact DGD does handle octal and hexadecimal integer constants as George
described. :-)
>>> Adjacent string constants are concatenated into a single string.
>>
>> DGD does not do this.
>
> This is ANSI C. Any reason why DGD does not do it?
I speculate the reason is it is a simple matter to use the + operator, which
accomplishes the same task and lends itself to more readable code. Good LPC
compilers will optimize this into a single string constant at compile time.
--
Robert Leslie
rob@ccs.neu.edu
From nobody@nightmare.imaginary.com Mon Aug 21 20:43:04 1995
Sender: nobody@nightmare.imaginary.com
Date: Mon, 21 Aug 1995 23:31:43 +0300
From: Petri Virkkula
To: lpc-language@imaginary.com
Subject: Re: Spec for LPC
On Mon, 21 Aug 1995 13:31:50 -0500 (CDT), George Reese said:
[cut]
George> If people paid any attention to it, it could. I suppose what I am
George> trying to say is that I do not want to get into a situation where
George> anyone is saying things like "DGD is really LPC, but LPMud 3.2 is
George> not." So perhaps I have mis-worded the above, especially since any
George> such document would hopefully be ignored by people.
[cut]
George> MudOS will be implementing some sort of exception handling beyond
George> catch() and error(). This set of "sometimes keywords" included what
George> little I knew about Beek's plans.
I think the spec/documentation/whatever should *only* state
features that all drivers have (and perhaps have _appendixes_
for features that only one or more drivers support). Or it
should contain full blown specification.
IMHO you should mention features specific only to one
driver in the main body of the document. Ie. you should make
greater distinction between common and driver specific
features.
Petri
From nobody@nightmare.imaginary.com Mon Aug 21 20:43:17 1995
Sender: nobody@nightmare.imaginary.com
Date: Mon, 21 Aug 95 14:05:02 -0700
To: lpc-language@imaginary.com
Subject: Re: Spec for LPC
From: apang@mindlink.bc.ca (Anthon Pang)
Hmm...Brandon V didn't happen to prompt this effort, did he? ;)
My two cents Canadian:
A "specification" is how something _should_ work. A "implementation" is
how it _does_ work. As a technical reference, these two details should be
clearly separated. It may be a bit of a misnomer to call this doc a
specification, since it goes into behavioural (implementation) differences
among the LPC dialects.
In the case of LPC, it is the grammar which is the bulk of the
specification. If you look at K&R, the spec. is summarized in an appendix.
Preprocessor and library functions (== LPmud efuns) are treated separately.
The rest of the book is an intro to C programming.
Perhaps, it should be called the "LPmud Specification and Implementation".
Of course, the scope of such a text would be HUGE. ;)
"Standard" and "non-standard" don't really apply, since there wasn't a
formal specification that declared the "standard". In lieu of that, which
LPmud version should be considered the base "standard"? Where Lars left
off? or where Amylaar took it? Perhaps, "common" and "extensions" are
more apt descriptions.
In particular, the section entitled "non-standard keywords" should read
"reserved keywords". It should be noted that the only reasons words like
"sscanf" are reserved are because:
- it's easier for the lexer
- it avoids potential debugging problems where the keyword is used as
a variable
- it disambiguates the possibility of "overriding" it
- there is no "standard" method to pass lvalues as parameters in LPC
WRT escape sequences, MudOS also has "\e" for the escape character.
I will say that the presence of a specification is a good thing. I think
George's draft is at least headed in the right direction. Hmm...does that
mean we'll have to stop calling ourselves "driver hackers"? >=)
I'll probably have more comments as I re-read it. And I may have some
ideas to share from the "MudOS Technical Reference"--a LaTeX document I
started, but haven't (never?) finished. =\ *sigh*
-- Anthon
From nobody@nightmare.imaginary.com Mon Aug 21 20:44:40 1995
Sender: nobody@nightmare.imaginary.com
From: George Reese
Posted-Date: Mon, 21 Aug 1995 16:06:32 -0500
Subject: Re: Some notes on various implementations
To: lpc-language@imaginary.com
Date: Mon, 21 Aug 1995 16:06:31 -0500 (CDT)
Robert Leslie once wrote...
>
> >> DGD does not have // comments.
> >
> > Why not? They are quite useful at times, especially if you are using
> > an editor capable of easily generating and deleting such comments.
>
> While I have no interest in fueling a style debate on the use of // comments,
> they are not implemented in DGD because Dworkin doesn't want them.
>
I suppose you cannot find a more base reason than that, still, I would
think it a nice, trivial addition rather than a topic of contention.
Nuff said on the topic I suppose.
> >>> Adjacent string constants are concatenated into a single string.
> >>
> >> DGD does not do this.
> >
> > This is ANSI C. Any reason why DGD does not do it?
>
> I speculate the reason is it is a simple matter to use the + operator, which
> accomplishes the same task and lends itself to more readable code. Good LPC
> compilers will optimize this into a single string constant at compile time.
Actually, I think omitting the + lends to more readable code. But
that may simply be stylistic preference. My "objective" argument
would be that + is redundant code that takes up column space (in
other words, it is one of 80 columns you could better use for text...
if you space properly, it is 2). But the real point I am trying to
make is that with respect to C-like features, many aspects of LPC seem
to favour an ANSI decision (as with DGD floating constants). The
behaviour as i had formerly described it in the "spec" reflects ANSI.
However, I do agree that compilers should be optimized to see "a" + "e"
as being "ae" rather than doing runtime string concatenation. I have
no idea if other drivers do that.
--
George Reese (borg@imaginary.com) http://www.winternet.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From nobody@nightmare.imaginary.com Mon Aug 21 20:44:48 1995
Sender: nobody@nightmare.imaginary.com
Date: Mon, 21 Aug 95 14:12:06 -0700
To: lpc-language@imaginary.com
Subject: Re: Spec for LPC
From: apang@mindlink.bc.ca (Anthon Pang)
Oh...I think it would a nice addition to show what distinguishes LPC from
other C-like languages--eg C itself, C+@, Java, Quincy C/QC/D-Flat, C-Int,
...
But that's probably beyond the scope of this text.
-- Anthon
From nobody@nightmare.imaginary.com Mon Aug 21 20:44:55 1995
Sender: nobody@nightmare.imaginary.com
From: Kris Van Hees
Subject: Re: Some notes on various implementations
To: lpc-language@imaginary.com
Date: Mon, 21 Aug 1995 23:46:12 +0200 (MET DST)
George Reese mailed me:
> > > This is ANSI C. Any reason why DGD does not do it?
> >
> The real point I am trying to
> make is that with respect to C-like features, many aspects of LPC seem
> to favour an ANSI decision (as with DGD floating constants). The
> behaviour as i had formerly described it in the "spec" reflects ANSI.
>
Well... it has been pointed out in various newsgroups and such that LPC is
not C, nor ANSI C. I don't think it would do much good trying to assume
that LPC should follow certain ANSI C specifications for whatever reason.
LPC is not C, it is LPC. Bringing it closer to ANSI C isn't really going
to make things easier, and in all, probably only leads to more arguments.
Think of it like this... automatic concatenation of strings in ANSI C is
basically a result of the lack of any concatenation operator in C. Not
that I claim there should be one, by the way. There simply isn't any.
LPC has one, so it is the logical instrument to use to express the
concatenation of two strings :) I don't think it's any use trying to
find reasons to adopt the ANSI C version.
Aedil
From nobody@nightmare.imaginary.com Mon Aug 21 20:45:04 1995
Sender: nobody@nightmare.imaginary.com
Date: Mon, 21 Aug 95 14:25:11 -0700
To: lpc-language@imaginary.com
Subject: Re: Some notes on various implementations
From: apang@mindlink.bc.ca (Anthon Pang)
Just a note...but the 5 year review of the ANSI C spec is upon us, and
according to an article in DDJ, one consideration is to add // to the
preprocessor spec., given the number of C/C++ compilers which now support
it as an extension when processing .c files.
-- Anthon
From nobody@nightmare.imaginary.com Mon Aug 21 20:45:14 1995
Sender: nobody@nightmare.imaginary.com
Date: Mon, 21 Aug 95 15:15:37 -0700
To: lpc-language@imaginary.com
Subject: Re: Some notes on various implementations
From: apang@mindlink.bc.ca (Anthon Pang)
Kris Van Hees writes:
> LPC is not C, it is LPC.
> Bringing it closer to ANSI C isn't really going
> to make things easier, and in all, probably only leads to more arguments.
IMHO, since C is well-defined by a spec, making LPC behave in some respects
closer to C, helps to eliminate cases of unexpected behavior--for us C
folks. ;)
> Think of it like this... automatic concatenation of strings in ANSI C is
> basically a result of the lack of any concatenation operator in C. Not
> that I claim there should be one, by the way. There simply isn't any.
> LPC has one, so it is the logical instrument to use to express the
> concatenation of two strings :) I don't think it's any use trying to
> find reasons to adopt the ANSI C version.
Let's just remember that '+' string concatenation for constant strings was
not always a compile-time operation. And as I recall, one kludgey
implementation had it in the lexical analysis stage. *shudder*
Since MudOS supports both, let it a facet of the coder's style on which
he/she chooses to use. Or should we argue the merits of /* */ vs //, @ +
@@, tabs vs spaces, indentation, or why my favorite smilies aren't official
tokens yet
(= =) ?
From nobody@nightmare.imaginary.com Mon Aug 21 20:45:25 1995
Sender: nobody@nightmare.imaginary.com
From: George Reese
Posted-Date: Mon, 21 Aug 1995 17:24:20 -0500
Subject: Re: Some notes on various implementations
To: lpc-language@imaginary.com
Date: Mon, 21 Aug 1995 17:24:20 -0500 (CDT)
Kris Van Hees once wrote...
> Well... it has been pointed out in various newsgroups and such that LPC is
> not C, nor ANSI C. I don't think it would do much good trying to assume
> that LPC should follow certain ANSI C specifications for whatever reason.
> LPC is not C, it is LPC. Bringing it closer to ANSI C isn't really going
> to make things easier, and in all, probably only leads to more arguments.
>
I do not mean to insinuate anything about the relationship between LPC
and C. I certainly do not think that ANSI C should dictate how LPC
should appear (in fact, IMHO, the further away from C the better).
However, when sitting on a fence with no particular way to fall, what
others have done in the same situation can create that teeny amount of
momentum needed to drop to one side or another. In this case, the
related situation is ANSI C.
On the unfortunate side, I do not think either Dworkin or Amylaar
currently subscribe to this mailing list :(, so there is no way really
to tell how much on the fence Dworkin is with regards to this issue.
As an LPC coder, I simply find auto-concatenation of two strings a
nice feature.
--
George Reese (borg@imaginary.com) http://www.winternet.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
From nobody@nightmare.imaginary.com Mon Aug 21 20:45:29 1995
Sender: nobody@nightmare.imaginary.com
Subject: Re: Some notes on various implementations
To: lpc-language@imaginary.com
Date: Mon, 21 Aug 1995 17:49:54 -0500 (CDT)
> On the unfortunate side, I do not think either Dworkin or Amylaar
> currently subscribe to this mailing list :(, so there is no way really
> to tell how much on the fence Dworkin is with regards to this issue.
> As an LPC coder, I simply find auto-concatenation of two strings a
> nice feature.
Just as a note, 3.2/3.2.1 both support auto-concatenation, but it isn't
the default behavior. You enable it with a #pragma directive.
And yes, it is a nice feature. ;-)
A comment I'd like to make about the doc is wrt mappings...at least
3.2/3.2.1 support multi-value mappings, and MudOS did for a while at least.
You may want to make reference to the fact that some implementations have
support for multiple values to be bound to a key.
Also, is LPC4 going to be mentioned at all? As well, someone might want to
mention something to Demos about this, so he can participate with information
from Dome (which apparently will still be using an LPC-ish dialect)...
--
_ ___ _____________________________________________________________________
/ /__/\__ \
/ \ \ \/\ logic@common.net \
Help topics available:
You are guest number 143 since November 2019.
This file was last modified: June 2000.