scripting

Andreas Rrsdal <andrearo@stud.ntnu.no> wrote in
news:Pine.LNX.4.58.0501142200580.9967@tiger.stud.n tnu.no:

> On Fri, 14 Jan 2005, Nathan Mates wrote:
>> In article <Xns95DEC639EBC4DRaghar@195.250.128.45>,
>> Raghar <notfor@mail.com> 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?
>>
>> >No scripting, it's bit silly. If you have runtime compilation
>> >and ability to recompile your AI rutines at runtime.
>>
>> I don't think the original poster is talking about doing the
>> AI
>> routines as/in a scripting language. I think it's more in the
>> sense of in-mission scripting, much the way games like
>> Starcraft have the ability to play a voiceover, transfer units
>> to your team, etc when some objective is achieved.
>
> Yes, exactly. Scripting like in Starcraft or C&C Red Alert is
> what I'm interested in. Events in the game should trigger the
> scripting system, then the scripting system should perform some
> logic operations to decide which actions to take, and then
> somehow tell the game-code that it should do.
>
> However, the scripting system (the interaction between the game,
> the scripting language, events etc++) for a complex RTS game
> this can be a challenge to develop and maintain, I suspect.
> Therefore, I'd like to find out how the current games most
> likely are designed in this area.
>
Scripting systems arises from problems encountered during game
development.
You could have: "0,0,2,567, trigger GAMEEVENT1()"
Object on the map cross boundaries, then object descriptor is
notified, and GAMEEVENT1() method is resolved.
This is one of simplier ways. The object descriptor is loaded with
level (Of course you must do it a little differently for game
without levels.)
Then afer few years you might be interested in problem, how can I
use game scripting for my next version of the game.
The answer is you don't. You develop a new system optimalized for
next version, as was the previous reasonably optimal for previous
version. And it could be possibly backward compatible.

Some people created simplified C++, others based theirs scripting
"language" on Java (of course simplified).

Of course you could do it even this way
public class SoldierSoldi extends Soldi{
private int state = Soldi.DEFAULT;
applyDamage(int damage){
if(state != Soldi.IN_FIGHT){
state = Soldi.IN_FIGHT;
if(this.owner.stateOfUs(owner.NOT_ON_ALERT) >=
owner.anotherVariable){
// don't bother until...
owner.alert(this, damage);
// Mama it's S*E*R*I*OUS
} else {owner.info(this, damage);}
}
}
}
}


The most difficult thing isn't write down some representation of
the game state, the most difficult thing is use it fast and
reliably.

"Philippa Cowderoy" <flippa@flippac.org> wrote in message
news:Pine.WNT.4.61.0501161551370.1876@SLINKY...
> 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.
>
well, my idea is that the type inference would infer from what types it
knows, and leave everything it can't figure out as dynamic types.

however, type inferrence could be generated by state as well, eg: if you
assign a to a dynamic variable from a static one, one can infer that the
type of that var can't be changed if it can be verified that the var can't
be changed from where it is assigned and where it is used.

....

many use type inference, eg, on scheme, so I don't think it is that big of a
problem.

the main one would be declaring types for function arguments, as likely many
of the other types in a function can be inferred from these (with
constraints, eg, on control flow, creation of closures, ...).

>> 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.
>
maybe, but in some cases an "any" type can be useful, but typically this is
when passing the value to something else that accepts an any type, or
choosing what to do with it based on a registry, ...

>> 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.
>
well, the problem is, if you have 3 scope systems, which does it go into?...

new vars could default to lexical scope (makes sense within functions), or
they could default to object scope, or they could default to dynamic.

similarly, what if the coder mistyped the var name? accidentally assigning
to non-existant variables is a rather common problem, and getting complaints
is at least a basic safety net.

imo, it is better to require declaration, at the cost of a little typing.

>> 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.
>

well, for values I don't know anything about, at least I know I can fetch
the type name and go from there.

an example could be a function like 'drawsomething', with something being an
unknown type. one could use a registry for the great drawsomething, or maybe
a type based switch, ...

>> 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.
>
well, I am a c coder who prior to that point had a fair amount of experience
with scheme, and even some messing with erlang and similar.

the issue was trying to write anything that the typesystem would accept,
which was quite difficult.

the initial learning curve seems imo fairly high for haskell, but I will
also accept this complaint about c.

> 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.
>
ok.

>> 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.
>
it was actually a partial joke, oh well...

On Mon, 17 Jan 2005, cr88192 wrote:

>
> "Philippa Cowderoy" <flippa@flippac.org> wrote in message
> news:Pine.WNT.4.61.0501161551370.1876@SLINKY...
>> On Sun, 16 Jan 2005, cr88192 wrote:
>>> 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.
>>
> well, my idea is that the type inference would infer from what types it
> knows, and leave everything it can't figure out as dynamic types.
>

That'll do.

>>> 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.
>>
> maybe, but in some cases an "any" type can be useful, but typically this is
> when passing the value to something else that accepts an any type, or
> choosing what to do with it based on a registry, ...
>

In the latter case, surely it'd better to work with an "is in this
registry" type?

>>> 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.
>>
> well, the problem is, if you have 3 scope systems, which does it go into?...
>

Er, *ick*. DDTT?

> imo, it is better to require declaration, at the cost of a little typing.
>

I do tend to end up doing this for mutable variables, as I need a monadic
action to create them in the first place. For non-mutable variables, it
really doesn't save anything.

>> 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.
>>
>
> well, for values I don't know anything about, at least I know I can fetch
> the type name and go from there.
>

That's because you assume all values belong to the type "has fully known
type at run-time". Values outside that type have smaller representations.

> an example could be a function like 'drawsomething', with something being an
> unknown type. one could use a registry for the great drawsomething, or maybe
> a type based switch, ...
>

Or maybe have a typeclass Drawable with a member function draw, and then
you might have eg a list of values in Drawable.

>> 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.
>>
> well, I am a c coder who prior to that point had a fair amount of experience
> with scheme, and even some messing with erlang and similar.
>
> the issue was trying to write anything that the typesystem would accept,
> which was quite difficult.
>

Do you have any examples of things you were having difficulty with? For
that matter, could you write code in the simply typed lambda calculus
(that is, the lambda calculus with a few primitive types, a function type
constructor -> and a few variables given types ahead of time)?

The type system isn't all that horrendous. It is, however,
substantially different from either C or the various lisp dialects and
thus likely to require a similar amount of conceptual work to learning
them.

--
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

"Philippa Cowderoy" <flippa@flippac.org> wrote in message
news:Pine.WNT.4.61.0501170212420.1876@SLINKY...
> On Mon, 17 Jan 2005, cr88192 wrote:
>
>>
>> "Philippa Cowderoy" <flippa@flippac.org> wrote in message
>> news:Pine.WNT.4.61.0501161551370.1876@SLINKY...
>>> On Sun, 16 Jan 2005, cr88192 wrote:
>>>> 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.
>>>
>> well, my idea is that the type inference would infer from what types it
>> knows, and leave everything it can't figure out as dynamic types.
>>
>
> That'll do.
>
>>>> 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.
>>>
>> maybe, but in some cases an "any" type can be useful, but typically this
>> is
>> when passing the value to something else that accepts an any type, or
>> choosing what to do with it based on a registry, ...
>>
>
> In the latter case, surely it'd better to work with an "is in this
> registry" type?
>
but constraining this statically is likely not possible.

>>>> 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.
>>>
>> well, the problem is, if you have 3 scope systems, which does it go
>> into?...
>>
>
> Er, *ick*. DDTT?
>
what is ddtt?...

>> imo, it is better to require declaration, at the cost of a little typing.
>>
>
> I do tend to end up doing this for mutable variables, as I need a monadic
> action to create them in the first place. For non-mutable variables, it
> really doesn't save anything.
>
in a typical scripting language all variables are viewed as mutable.
however, typical scripting languages don't have mondad either...

>>> 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.
>>>
>>
>> well, for values I don't know anything about, at least I know I can fetch
>> the type name and go from there.
>>
>
> That's because you assume all values belong to the type "has fully known
> type at run-time". Values outside that type have smaller representations.
>
well, I am assuming a dynamically typed language, where this is assumed for
all types.

>> an example could be a function like 'drawsomething', with something being
>> an
>> unknown type. one could use a registry for the great drawsomething, or
>> maybe
>> a type based switch, ...
>>
>
> Or maybe have a typeclass Drawable with a member function draw, and then
> you might have eg a list of values in Drawable.
>
this is not allways reasonable.

>>> 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.
>>>
>> well, I am a c coder who prior to that point had a fair amount of
>> experience
>> with scheme, and even some messing with erlang and similar.
>>
>> the issue was trying to write anything that the typesystem would accept,
>> which was quite difficult.
>>
>
> Do you have any examples of things you were having difficulty with? For
> that matter, could you write code in the simply typed lambda calculus
> (that is, the lambda calculus with a few primitive types, a function type
> constructor -> and a few variables given types ahead of time)?
>
> The type system isn't all that horrendous. It is, however, substantially
> different from either C or the various lisp dialects and thus likely to
> require a similar amount of conceptual work to learning them.
>
I can't really understand typed lambda calculus myself either...

imo, however, a simple and generic typesystem is needed for scripting
language. imo the user shouldn't be burdened by having to worry about extra
stuff...

or whatever...

In article <yUDGd.340$rc4.277@fe07.usenetserver.com>, cr88192
@NOSPAM.hotmail.com says...

> similarly, what if the coder mistyped the var name? accidentally assigning
> to non-existant variables is a rather common problem, and getting complaints
> is at least a basic safety net.
>
> imo, it is better to require declaration, at the cost of a little typing.

That's an interesting point, but of course a language could easily
implement a 'new variable' keyword ('new' if it doesn't have new as a
keyword, 'newvar' if it does):

new a = rat
a.eatCheese

b.eatCheese
[ERROR - b NOT DECLARED]

new c = a
c.eatCheese
[OKAY]

Do any languages without forced type declaration have this? It seems a
reasonable proposal.

- Gerry Quinn

"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
news:MPG.1c55a262c8cf35a7989d28@news.indigo.ie...
> In article <yUDGd.340$rc4.277@fe07.usenetserver.com>, cr88192
> @NOSPAM.hotmail.com says...
>
>> similarly, what if the coder mistyped the var name? accidentally
>> assigning
>> to non-existant variables is a rather common problem, and getting
>> complaints
>> is at least a basic safety net.
>>
>> imo, it is better to require declaration, at the cost of a little typing.
>
> That's an interesting point, but of course a language could easily
> implement a 'new variable' keyword ('new' if it doesn't have new as a
> keyword, 'newvar' if it does):
>
> new a = rat
> a.eatCheese
>
> b.eatCheese
> [ERROR - b NOT DECLARED]
>
> new c = a
> c.eatCheese
> [OKAY]
>
> Do any languages without forced type declaration have this? It seems a
> reasonable proposal.
>
err, mine does, that is one of the main ways I can declare vars.

var foo=[x:=3, y:=4];

or such, and another variant is 'local', which does the same thing but for
lexical scope, and 'dynvar', for dynamic scope.


note, the right hand of the equals in such cases is an actual run-time
evaluated expression, and these can appear interspersed with normal code.

however, for reasons of having most of my experience in c, my style tends to
have all of them twards the top of scripts/functions, and assigned in
seperate statements.

function ffun()
{
local foo;

...

foo=[x:=3, y:=4];

...
}


misc: I do have a 'new' keyword, but given the workings of my language I
don't really use it and it comes off as kind of pointless.
namely:
I am considering dropping the 'new', 'clone', and 'object' keywords, for the
main reason of disuse by me, and the fact that they have alternate (and more
general) forms (new and clone in method forms, and object because of the
syntax given in the examples, which is a lot more terse anyways).

for now I will keep "begin_object" (basically, a fairly non-oo feature
allowing one to execute statements in another object).


now, unrealated is I have a keyword 'begin', which is dubious.
basically it is an alternative to a particularly common abuse of while:
while(1)
{
...
break;
}

is equivalent to:
begin
{
...
}

namely, it naturally runs through once, but if one uses continue, they can
iterate multiple times.


let has allready been dropped, as it offers nothing really over a special
case of 'fun'.
basically, creating a (possibly recursive) annonymous function which is
immediately called is not that much more awkward, is more general, and
leaves less to maintain.

....

basically, some things seemed like a good idea at the time, but were fairly
pointless in general.

let(x=3, y=4)
{
...
}

vs:
fun(x, y)
{
...
}(3, 4);


yes, the latter looks weirder, but saves in a construct.
....

On Mon, 17 Jan 2005, cr88192 wrote:

>
> "Philippa Cowderoy" <flippa@flippac.org> wrote in message
> news:Pine.WNT.4.61.0501170212420.1876@SLINKY...
>> On Mon, 17 Jan 2005, cr88192 wrote:
>>
>>>
>>> maybe, but in some cases an "any" type can be useful, but typically this
>>> is
>>> when passing the value to something else that accepts an any type, or
>>> choosing what to do with it based on a registry, ...
>>>
>>
>> In the latter case, surely it'd better to work with an "is in this
>> registry" type?
>>
> but constraining this statically is likely not possible.
>

If the registry's static it's entirely possible and Haskell coders have
been doing it for well over a decade. I'll have to check how old
existential types and/or rank-2 polymorphism in Haskell compilers is, but
those give you full flexibility with such types.

So the question becomes "do you need the registry to be dynamic?" - I
don't find that's often true.

>>> well, the problem is, if you have 3 scope systems, which does it go
>>> into?...
>>>
>>
>> Er, *ick*. DDTT?
>>
> what is ddtt?...
>

Don't Do That Then.

>>> an example could be a function like 'drawsomething', with something being
>>> an
>>> unknown type. one could use a registry for the great drawsomething, or
>>> maybe
>>> a type based switch, ...
>>>
>>
>> Or maybe have a typeclass Drawable with a member function draw, and then
>> you might have eg a list of values in Drawable.
>>
> this is not allways reasonable.
>

Got any good examples of where it isn't? The only one that comes to mind
is a situation where not all the code is present at compile-time.

>>> the issue was trying to write anything that the typesystem would accept,
>>> which was quite difficult.
>>>
>>
>> Do you have any examples of things you were having difficulty with? For
>> that matter, could you write code in the simply typed lambda calculus
>> (that is, the lambda calculus with a few primitive types, a function type
>> constructor -> and a few variables given types ahead of time)?
>>
>> The type system isn't all that horrendous. It is, however, substantially
>> different from either C or the various lisp dialects and thus likely to
>> require a similar amount of conceptual work to learning them.
>>
> I can't really understand typed lambda calculus myself either...
>

That's not a good sign. Aside from removing the possibility of
higher-order functions there's nothing you could do to make the simply
typed lambda calculus simpler. Primitive types are equal iff they've got
the same name, (a->b) == (c->d) iff a == b and c == d and types can't be
recursively defined. Function applications work exactly how you'd expect -
the parameter given for a function must match the LHS of the function's
type, and the result is the RHS.

So, given that a has the type "Foo -> Bar", b has the type "Bar", and c
has the type "Foo", the function application a b (or a(b) for those
clinging to C syntax) is badly typed whereas the application a c has the
type Bar.

I have to admit to being somewhat confused as to how somebody can get C's
type system but not this - the only real differences are syntax and the
fact you get some higher-order functions.

--
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

"Philippa Cowderoy" <flippa@flippac.org> wrote in message
news:Pine.WNT.4.61.0501171554220.664@SLINKY...
> On Mon, 17 Jan 2005, cr88192 wrote:
>
>>
>> "Philippa Cowderoy" <flippa@flippac.org> wrote in message
>> news:Pine.WNT.4.61.0501170212420.1876@SLINKY...
>>> On Mon, 17 Jan 2005, cr88192 wrote:
>>>
>>>>
>>>> maybe, but in some cases an "any" type can be useful, but typically
>>>> this
>>>> is
>>>> when passing the value to something else that accepts an any type, or
>>>> choosing what to do with it based on a registry, ...
>>>>
>>>
>>> In the latter case, surely it'd better to work with an "is in this
>>> registry" type?
>>>
>> but constraining this statically is likely not possible.
>>
>
> If the registry's static it's entirely possible and Haskell coders have
> been doing it for well over a decade. I'll have to check how old
> existential types and/or rank-2 polymorphism in Haskell compilers is, but
> those give you full flexibility with such types.
>
> So the question becomes "do you need the registry to be dynamic?" - I
> don't find that's often true.
>
ok, yes, it does not need to be dynamic, but in most languages it is not
possible to have it static.

mind you, I am personally under the impression that haskell's learning cure
is a bit high for a scripting lang.

mind you, the typical user doesn't want to need to "understand" the
language, but more likely copy and paste fragments, and edit others, and
hope for it to work.

>>>> well, the problem is, if you have 3 scope systems, which does it go
>>>> into?...
>>>>
>>>
>>> Er, *ick*. DDTT?
>>>
>> what is ddtt?...
>>
>
> Don't Do That Then.
>
ok.
I require definitions, mostly as to make this clear.

just like I have 'function' and 'lfunction' (the former object, the latter
lexical).
I don't have a variety for dynamic scope, as afaik the cases where one needs
to use dynamic scope are rare enough, and it is imo sufficient to use a
dynamic var and a closure.

dynvar f=fun(x, y)sqrt(x*x+y*y);

this could also be done with lexical functions, but imo there are other
reasons to have a dedicated form:
there are many cases where lexical bound functions will be needed;
it is imo nicer to provide dedicated forms for this;
it allows specifying functions that check for a specific pattern otherwise
passing to the next (previous) function, ...

>>>> an example could be a function like 'drawsomething', with something
>>>> being
>>>> an
>>>> unknown type. one could use a registry for the great drawsomething, or
>>>> maybe
>>>> a type based switch, ...
>>>>
>>>
>>> Or maybe have a typeclass Drawable with a member function draw, and then
>>> you might have eg a list of values in Drawable.
>>>
>> this is not allways reasonable.
>>
>
> Got any good examples of where it isn't? The only one that comes to mind
> is a situation where not all the code is present at compile-time.
>
yes, this is one.
another is when the underlying primitives don't exist within the language,
but are implemented, say, at the c level.

other situations are imo possible.

>>>> the issue was trying to write anything that the typesystem would
>>>> accept,
>>>> which was quite difficult.
>>>>
>>>
>>> Do you have any examples of things you were having difficulty with? For
>>> that matter, could you write code in the simply typed lambda calculus
>>> (that is, the lambda calculus with a few primitive types, a function
>>> type
>>> constructor -> and a few variables given types ahead of time)?
>>>
>>> The type system isn't all that horrendous. It is, however, substantially
>>> different from either C or the various lisp dialects and thus likely to
>>> require a similar amount of conceptual work to learning them.
>>>
>> I can't really understand typed lambda calculus myself either...
>>
>
> That's not a good sign. Aside from removing the possibility of
> higher-order functions there's nothing you could do to make the simply
> typed lambda calculus simpler. Primitive types are equal iff they've got
> the same name, (a->b) == (c->d) iff a == b and c == d and types can't be
> recursively defined. Function applications work exactly how you'd expect -
> the parameter given for a function must match the LHS of the function's
> type, and the result is the RHS.
>
> So, given that a has the type "Foo -> Bar", b has the type "Bar", and c
> has the type "Foo", the function application a b (or a(b) for those
> clinging to C syntax) is badly typed whereas the application a c has the
> type Bar.
>
ok.

this actually sort of makes sense.
I forget what a book I once had on typed lambda calculus was going on about,
I seem to have lost it...


> I have to admit to being somewhat confused as to how somebody can get C's
> type system but not this - the only real differences are syntax and the
> fact you get some higher-order functions.
>

well, there is some fundamental difference somewhere afaik.
the problem is I am not really fammiliar with "simply typed lambda
calculus", but am sort of with "typed lambda calculus" (to the point to
where my head died and I forgot the rest).
of course, I understand untyped lambda calculus fair enough afaik.


one gets used to the notion that everything is either one of the builtin
types, a renamed form of a builtin type, a struct, or a union.
other possibilities don't really exist (well, entirely within c realms, but
one can go around c if they so feel like it). personally I don't view enums
as really a type, as really an enum is an int and a means for declaring
constants, more sort of a mock-up type.

otherwise, the compiler doesn't care much, and only slightly cares when you
implicitly cast a pointer to an int or such.
the renaming of types doesn't matter much, it is more a convention thing.

however, it is sometimes useful, eg, when you have a bunch of things that
use int and you want to change them to long long, but as a cost you hide a
little info about what the type is (wrt the hw), so this can be both good or
bad.


eg:
I currently use 'void *' for all my dynamically typed values. I could define
something else, eg, 'netval', 'pddynamic', or 'pdvariant'. on one hand, it
makes it clear that just any-ol' pointer will not work, but may hide the
fact that in most cases a cast is all that is needed to convert.

so, I am leaning between sticking to my 'void *' convention, or going to
something like 'pdvariant'...


one doesn't think much about the types abstractly though, but more "this is
in reality a 32 bit integer", in which case one knows the effective range
and compiler behavior.

one remembers the way things are packed in structs, and the alignment rules
(note: officially it may not be defined, but in practical manners, certain
behavior is typically expected and sometimes relied upon).

otherwise, the struct becomes mentally a bag of slots.

....

one, however, does not think much of how the types are treated, transformed,
.... or maybe one sort of learns and gets it internalized, or whatever (eg:
like for a struct or union whether you use '.' or '->' depends on whether
you have a direct value or a pointer, ...).

just, haskell does not come that easily really in my experience.
the type system seems rather alien, like some sort of abstract pattern
matching and definition oddity or whatever, vs. the more strict and more
limited almost in-memory definition of c.


a lot of effort is expended in worrying how structs are organized, and the
cost and layout of things in memory, this is largely what "types" become...

(note: this does not necissarily apply to c++, which imo tends to be a bit
more abstract in many places...).

or 'tis my narrowly defined oppinion...

really: I can't see the forest from the trees.
or, also: I am fairly bad at abstracting things.

Philippa Cowderoy <flippa@flippac.org> wrote in
news:Pine.WNT.4.61.0501161551370.1876@SLINKY:

> 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
It's often used in Java. I think it's workaround from three different
problems.

safeTypeCheck(Object o){
}
or drawRats(Object o){
}
of course you could put in even cats.

cr88192 wrote:

> mind you, I am personally under the impression that haskell's learning
cure
> is a bit high for a scripting lang.

Scripting language != designer's interface.

We need to give designers a clean, high-level interface that allows them to
focus on their job.

I suspect that the best scripting system is one with a language that allows
_programmers_ to then create such an interface. Then programmers respond to
cruft written by designers, and refactor that under the interface, extending
its abilities.

In this model (which, so far, is only imaginary), it seems that designers
never cut a class, hence the scripting language's learning curve is less
important.

Haskell might be the exception ;-)

> mind you, the typical user doesn't want to need to "understand" the
> language, but more likely copy and paste fragments, and edit others, and
> hope for it to work.

And that's why programmers attend to this code at all times, and don't allow
designers to have their way with it.

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