scripting

Percival wrote:

> The ones are:
> Scheme through Guile and other interpreters
> Python
> Perl
> Lua
> Ruby
>
> I have not found much on Java, probably because it isn't used for this,
> though I am not sure.
>
> And, being one of the few programmers who likes scheme I'll recommend
> you do scheme for the heck of it, cause i know no advantage/disadvantage
> to any of these things anyway.

Lua is the front runner, even if for no other reason than...

- it shreds
- it does not build-in regular expressions

Rexexps should be used upstream from a game, but they have no place inside
the gaming box. (In my exalted opinion

Java is not on the list because it is statically typed. The point of a
scripting language is the high-level command-and-control code. Static typing
would just slow programmers down. The low-level code can use static typing,
so the script should at least alternate its paradigm.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

In article <RA%Fd.9228$Vj3.6739@newssvr17.news.prodigy.com> ,
Phlip <phlip_cpp@yahoo.com> wrote:
>Lua is the front runner, even if for no other reason than...
> - it shreds
> - it does not build-in regular expressions

Once again, I have to say: have you *EVER* used what you're trying
to promote? What projects have you used with Lua in them? How many
lines of Lua have you written, personally? Have you even read the
documentation on it? Why don't you go read
http://www.lua.org/manual/5.0/manual.html#5.3 (scroll down to the
string.gsub section) and "clarify" your second point above.

Nathan Mates

--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

"Percival" <dragontamer5788@yahoo.com> wrote in message
newsan.2005.01.15.02.40.09.21914@yahoo.com...
> On Thu, 13 Jan 2005 22:34:30 +0100, Andreas Røsdal wrote:
>
>> What is the most common way to implement scripting in a general RTS game?
>> Development in C/C++. Is yacc/lex a good solution? python? make a
>> special-purpose recursive descent parser?
>>
>> Andreas
>
> I don't know much on this subject, and have only begun research on it. But
> I'll tell you that there seems to be a few popular prebuilt scripting
> languages popping up.
>
> The ones are:
> Scheme through Guile and other interpreters
> Python
> Perl
> Lua
> Ruby
>
> I have not found much on Java, probably because it isn't used for this,
> though I am not sure.
>
> And, being one of the few programmers who likes scheme I'll recommend
> you do scheme for the heck of it, cause i know no advantage/disadvantage
> to any of these things anyway.
>
well, previously I have liked scheme.
then more recently I created a language and have a strong bend twards c
syntax.

now, I am thinking: people don't really give a crap. many languages with
non-c syntax are popular after all, so syntax probably isn't that big of a
deal.


then I am using something which is using tcl for its commands, though I have
my complaints about tcl, it has a low typing overhead in the simple cases.

this sort of reminds me of part of why I had used a postscript like language
for some things in my project. it is highly unreadable (vs tcl, or most
other langs for that matter), but it saves in typing.
the recent influence of something I am messing with (namely brl-cad, for
which I await a windows port) points out that there are still good reasons
to keep around a language resembling postscript:
it is fairly good for commands and deals fairly elegantly with chaining
things together, if one can stand the rpn, and my still not exactly
convinient scoping model...

failing that, something like tcl would come in next, it is less expressive
but has a more natural seeming structure.
next would be scheme (the main issue here imo would be parens).
a language with c like syntax would come in 4th, namely because of the need
of extra characters (parens, commas, and semicolons).
....

I am thinking maybe I wasn't respecting the language enough.


of course, I wouldn't want to see the result of someone trying to do a large
amount of game scripting in postscript (beyond maybe a kind of morbid
curiosity...).

On Sat, 15 Jan 2005, cr88192 wrote:

> next would be scheme (the main issue here imo would be parens).

Try implementing I-expressions (possibly by preprocessor)? There's a full
SRFI for them, they let you eliminate a lot of parens by using indentation
to indicate where they'd go.

--
flippa@flippac.org

Performance anxiety leads to premature optimisation

On Sat, 15 Jan 2005, Phlip wrote:

> Java is not on the list because it is statically typed. The point of a
> scripting language is the high-level command-and-control code. Static typing
> would just slow programmers down.

This IMO is a common misconception propagated by those who've never had
the chance to use a really really /good/ static typing system (C++, Java
et al don't count admittedly). Type inference in particular removes a
large part of the "I changed one type and now I have to propagate it"
problem, parametric polymorphism also being an effective tool against it.

--
flippa@flippac.org

Sometimes you gotta fight fire with fire. Most
of the time you just get burnt worse though.

Philippa Cowderoy wrote:

> Phlip wrote:
>
> > Java is not on the list because it is statically typed. The point of a
> > scripting language is the high-level command-and-control code. Static
typing
> > would just slow programmers down.
>
> This IMO is a common misconception propagated by those who've never had
> the chance to use a really really /good/ static typing system (C++, Java
> et al don't count admittedly). Type inference in particular removes a
> large part of the "I changed one type and now I have to propagate it"
> problem, parametric polymorphism also being an effective tool against it.

I appreciate how much more you know about static typing than I, but I was
pushing _dynamic_ typing for the scripting layer. The layer where you don't
give a hoot what something's type is, so long as you can invoke its methods.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

On Sat, 15 Jan 2005, Phlip wrote:

> Philippa Cowderoy wrote:
>
>> Phlip wrote:
>>
>>> Java is not on the list because it is statically typed. The point of a
>>> scripting language is the high-level command-and-control code. Static
> typing
>>> would just slow programmers down.
>>
>> This IMO is a common misconception propagated by those who've never had
>> the chance to use a really really /good/ static typing system (C++, Java
>> et al don't count admittedly). Type inference in particular removes a
>> large part of the "I changed one type and now I have to propagate it"
>> problem, parametric polymorphism also being an effective tool against it.
>
> I appreciate how much more you know about static typing than I, but I was
> pushing _dynamic_ typing for the scripting layer. The layer where you don't
> give a hoot what something's type is, so long as you can invoke its methods.
>

See comment about polymorphism. The relevant type is "has <listofmethods>"
or something equivalent - something that's perfectly possible with static
typing. In fact, that and "can be taken apart like so" are about the only
things I bother typing for.

--
flippa@flippac.org

Performance anxiety leads to premature optimisation

"Philippa Cowderoy" <flippa@flippac.org> wrote in message
news:Pine.WNT.4.61.0501151616320.1400@SLINKY...
> On Sat, 15 Jan 2005, cr88192 wrote:
>
>> next would be scheme (the main issue here imo would be parens).
>
> Try implementing I-expressions (possibly by preprocessor)? There's a full
> SRFI for them, they let you eliminate a lot of parens by using indentation
> to indicate where they'd go.
>
for command entry there is the problem that an indentation (and presumably
line-break) sensative syntax would require multiple lines, and cost in that
it would be unclear (from previous lines) when to stop expecting lines and
just interpret the entered commands (unless one were using the 'blank line'
convention or similar).

much simpler and more general would be just to omit the outermost parens for
command entry (essentially giving something like logo).
or: s-exps with a special case.

of course, for single line entry there is probably not much signifigant
difference...

or whatever...

"Philippa Cowderoy" <flippa@flippac.org> wrote in message
news:Pine.WNT.4.61.0501151617570.1400@SLINKY...
> On Sat, 15 Jan 2005, Phlip wrote:
>
>> Java is not on the list because it is statically typed. The point of a
>> scripting language is the high-level command-and-control code. Static
>> typing
>> would just slow programmers down.
>
> This IMO is a common misconception propagated by those who've never had
> the chance to use a really really /good/ static typing system (C++, Java
> et al don't count admittedly). Type inference in particular removes a
> large part of the "I changed one type and now I have to propagate it"
> problem, parametric polymorphism also being an effective tool against it.
>
what does the idea of wanting to allow optional use of type declarations and
type inference count as?

eg, would it be static, as some (or possibly most) vars and args would end
up with type names, or dynamic, because it is perfectly resonable to not
bother at the cost of likely less efficient code and more heap overhead?...

I had considered this, and considered calling "partial-static typing", but I
wonder what others would call it...

similar but inverse to this is imo static type systems with a "variant"
type. though functionally similar, one has to explicitly declare a var as
variant in many of them, and they may lack some of the features for managing
dynamic types or to such (imo misguided) things as automatic type conversion
(I don't believe in this for the main reason that, if one is passing the
*wrong* type, then quite likely it is an error).

similarly, I believe in the need to declare vars, even if for the sole
reason of defining what scope-system it is in.

why not static typing then? in most languages I have used, static typing
does not help with the use of dynamic constructs. one can't easily create "a
function that accepts whatever", which is imo sometimes useful.
you get "whatever", then you check the type of "whatever" and decide what to
do.

in the case of some languages (haskell comes to mind), for someone who
doesn't have a strong grasp on the language, one goes through hell even
trying to write simple functions (yes, one could argue, this is true of many
languages, but when even a generally experienced coder goes through hell,
then imo there is a problem...).

a haskell style type system, however, would imo make a nice (optional)
addition to a dynamically typed language (ommiting the fact that I am unsure
how such a typesystem would manage the transitions from dynamic to static in
an efficient manner, namely, without pattern matching checks or such...).

On Sun, 16 Jan 2005, cr88192 wrote:

>
> "Philippa Cowderoy" <flippa@flippac.org> wrote in message
> news:Pine.WNT.4.61.0501151617570.1400@SLINKY...
>> On Sat, 15 Jan 2005, Phlip wrote:
>>
>>> Java is not on the list because it is statically typed. The point of a
>>> scripting language is the high-level command-and-control code. Static
>>> typing
>>> would just slow programmers down.
>>
>> This IMO is a common misconception propagated by those who've never had
>> the chance to use a really really /good/ static typing system (C++, Java
>> et al don't count admittedly). Type inference in particular removes a
>> large part of the "I changed one type and now I have to propagate it"
>> problem, parametric polymorphism also being an effective tool against it.
>>
> what does the idea of wanting to allow optional use of type declarations and
> type inference count as?
>
> eg, would it be static, as some (or possibly most) vars and args would end
> up with type names, or dynamic, because it is perfectly resonable to not
> bother at the cost of likely less efficient code and more heap overhead?...
>

*All* variables are going to end up with types, because otherwise type
inference can't work. The types may occasionally be as general as
forall a.a ("works on any type"), but they'll be there because otherwise
the inference algorithm has nothing to infer from.

> similar but inverse to this is imo static type systems with a "variant"
> type. though functionally similar, one has to explicitly declare a var as
> variant in many of them, and they may lack some of the features for managing
> dynamic types or to such (imo misguided) things as automatic type conversion
> (I don't believe in this for the main reason that, if one is passing the
> *wrong* type, then quite likely it is an error).
>

A variant type that accepts all values is pretty useless. One that only
accepts some values and offers a means of telling which type it belongs to
at any given moment is damn useful - to the extent that I'm inclined to
believe the best form of dynamic typing is a really good static typing
system plus a safe casting mechanism.

> similarly, I believe in the need to declare vars, even if for the sole
> reason of defining what scope-system it is in.
>

I prefer to have variables implicitly declared when I first give them a
value, but that's just me.

> why not static typing then? in most languages I have used, static typing
> does not help with the use of dynamic constructs. one can't easily create "a
> function that accepts whatever", which is imo sometimes useful.
> you get "whatever", then you check the type of "whatever" and decide what to
> do.
>

There aren't many useful functions you can write on values you don't know
anything about - the identity function, building pairs, stuff like that.
The interesting question is how much you can do with values you don't know
/everything/ about - with a lil' work you can do a hell of a lot.

> in the case of some languages (haskell comes to mind), for someone who
> doesn't have a strong grasp on the language, one goes through hell even
> trying to write simple functions (yes, one could argue, this is true of many
> languages, but when even a generally experienced coder goes through hell,
> then imo there is a problem...).
>

The problem AFAICT is not understanding the underlying paradigm at all.
Somebody brought up on Haskell would have a similar problem moving to C -
not having a strong grasp on imperative programming will hurt a C coder
as much as not having a strong grasp on functional programming will hurt
a Haskell coder.

It *is* worth noting that the Haskell community often does a bad job of
teaching people how IO works, though this is starting to shift.

> a haskell style type system, however, would imo make a nice (optional)
> addition to a dynamically typed language (ommiting the fact that I am unsure
> how such a typesystem would manage the transitions from dynamic to static in
> an efficient manner, namely, without pattern matching checks or such...).
>

It wouldn't. But read up on type classes - coupled with the
commonly-implemented n-rank polymorphism extension they buy you a lot of
what's useful.

--
flippa@flippac.org

'In Ankh-Morpork even the shit have a street to itself...
Truly this is a land of opportunity.' - Detritus, Men at Arms