🔒 Locked

Scripting Language Features

Started by mongrelprogrammer Sep 17, 2005 at 3:52 PM 31 replies 7.2k views

Original Post

Sep 17, 2005 at 3:52 PM

I am in the midst of working on a compiler / interpreter for a research project which, interestingly enough, has no hard and fast languages requirements. Leaving me free to define the language itself. I thought I would ask a community which uses scripting languages what language features they would like to see. Personally I intend on allowing for closures and interfaces (if not all out OO). Other things I have considered are operator overloading and native calls into the code from a few other languages (though this isn't really a _language_ feature). So if you were looking for a new scripting language what features would you want? What really pissed you off about other languages? What do you love about them? What do you wish they had? Notes: 1.) I appologize if this is the wrong forum - but I wanted to target those who actually use scripting languages. (Mods: I understand if you feel the need to move tihs thread) 2.) I have no desire to work with an already defined language (what is the fun in that?). 3.) I am more then aware of the size and difficulty of compilers - this isn't the first time I have writen one. So... let me have it ;) Edit: Please mod me down. I hate these mod points. (Seriously)

mongrelprogrammer

Author

mongrelprogrammer

Sep 17, 2005 at 4:06 PM

Quote:
Original post by Anonymous Poster
Easy inferfacing with C/C++, java, python, etc,

Which languages / compilers do you find most likely to have people desiring that? Seeing as each language will have different calling methods? (In fact the 4 your listed have 3 very different calling methods). But your point is well taken - thanks :)

Quote:
Original post by Anonymous Poster
...and something new to offer.

You need something new. You need something that makes you better than python or lua or what have you.

I really don't... I have no desire to compete with other scripting languages - only to make a research project be even slightly useful :P

- Please mod me down. I hate these mod points. (Seriously) -

Extrarius

234

Extrarius

Sep 17, 2005 at 10:24 PM

Personally, I'd like to see more language eliminate operators. Why should '+' be special? Either get rid of infix notation (like Lisp and Scheme etc have done) or define a standard syntax so any function can be made infix.

Maybe something like

function infix(3) ? : (test, true_part, false_part)
{
if(test) return true_part;
else return false_part
}

That would define the ternary ?: operator in C++ (well, depending on the way things are evaluated it might not be exactly the same) - it takes 3 parameters and thus needs 2 'operator symbols' which are "?" and ":"

Even if you don't do that, it'd be nice to have just about any character in symbol names, so you could have functions like BooleanValue?() or MakeChange!()

mongrelprogrammer

Author

mongrelprogrammer

Sep 17, 2005 at 11:42 PM

Quote:
Original post by Extrarius
Personally, I'd like to see more language eliminate operators. Why should '+' be special? Either get rid of infix notation (like Lisp and Scheme etc have done) or define a standard syntax so any function can be made infix.

An interesting point. I agree that the language itself shouldn't have special cases not usable by the actual programmer. I don't really want to go the route of no infix operators - to many people (myself included) like mathematical expressions to look like mathematical expressions.

At the same time it would require some interesting parser work to get something like what you showed to parse (sounds fun :P ). Prolog actually has something somewhat like this by linking operators to atoms using:

op(Priority, Associativity, Atom)

The priority in this case is an integer from 0 to 1200 I belive. I am not sure I like using numbers for priority though - so I would have to think of a nice way of indicating that.

Still - an interesting idea. I think I will have to make use of that, if only to force the parser to be that much more versatile.

Quote:
Original post by Extrarius
Even if you don't do that, it'd be nice to have just about any character in symbol names, so you could have functions like BooleanValue?() or MakeChange!()

Not sure about this one though. If the special characters were operators spaces would be required in a large portion of the code and could create some strange errors. Such as if Func+(arg) and + were both defined. Though perhaps if operators can already be created a space between Func and + should be as expected as a space between two function names. I will have to think about the style implication of this one.

Thanks for some great ideas!

umbrae

Sep 18, 2005 at 4:13 AM

Delegates (or states)

This is where a group of classes subclass a common parent class but don't add any extra methods or properties. An instance of any one of the classes can have it's class swaped to one of the other sub-classes at runtime, but still keeps all the information in it's properties.

This is great for game development because a lot of functionality can be worked out in terms of states. A character goes through a lot of different states (walking / running / crouching / dying).

The good thing about this is there is no overhead (apart from your implementation of a vtable) to have multiple states... the actual class of the object gets changed.

I'm working on a language and virtual machine myself:

Planned Features | Progress

CJM

Sep 18, 2005 at 5:22 AM

Hey,

My vote would have to be with full use of the unicode [or ascii, I guess, but it won't be the samep] charset.

I mean, the only other language that I've heard of that's supposed to actually do that properly is Fortress, and although it may be difficult to type [an intellisense type system would be invaluable for any IDE], being able to define mathematical constants like pi in their native character would be very handy. And being able to override operators like sigma for lists and that sort of stuff would be really really nice.

Secondly, if you're doing something OOP, it would be nice to have some way to convert a function like class.Object(int param) into a global function Class::Object(Class* obj, int param) easily. That's always irritated me.

Also, it's kind of a more sidenotey thing, but a nice set of speed/functionality choices [runtime would be cool, but only for cool's sake], so that you can lie somewhere between Java and C in what you want to do, for example enable and disable memory zeroing, check that objects aren't writing to other objects' memory, etc.

Just some suggestions. I don't know if any of them are any good, but it's just some stuff that may be useful.

--CJM

mongrelprogrammer

Author

mongrelprogrammer

Sep 18, 2005 at 10:33 AM

Quote:
Original post by umbrae
Delegates (or states)

This is where a group of classes subclass a common parent class but don't add any extra methods or properties. An instance of any one of the classes can have it's class swaped to one of the other sub-classes at runtime, but still keeps all the information in it's properties.

Are you refering to C# delegates? This doesn't quite sound like the delegates I am familiar with (being roughly function pointers (over simplification)). Any references on the type of delegates you are talking about?

I read your page where you talk about delegates and it sounds like an interface or pure virtual class could easily take the place of delegates.

Quote:
Original post by umbrae
I'm working on a language and virtual machine myself:

Planned Features | Progress

Looks nice :) How far are you along in your creation?

Quote:
Original post by CJM
My vote would have to be with full use of the unicode [or ascii, I guess, but it won't be the samep] charset.

That would be interesting. And would make for some interesting screen shots :P I will have to look into that. I am worried about the finding a line between 'whitespace' and actual tokens in the language. Not to mention I am not sure I like the idea of requireing a unicode editor (are there any source code editors that support unicode?).

Quote:
Original post by CJM
Secondly, if you're doing something OOP, it would be nice to have some way to convert a function like class.Object(int param) into a global function Class::Object(Class* obj, int param) easily. That's always irritated me.

Can't you do that in C++ already? Using something like obj->Object(param)? Maybe encapsulate that into a templated function? In any case I take it you want some type of function pointer into an object's methods - which honestly I would have to say I would prefer to have an interface for that function as a pointer to the class.

Quote:
Original post by CJM
Also, it's kind of a more sidenotey thing, but a nice set of speed/functionality choices [runtime would be cool, but only for cool's sake], so that you can lie somewhere between Java and C in what you want to do, for example enable and disable memory zeroing, check that objects aren't writing to other objects' memory, etc.

I already plan to have a fully descriptive and selectable optimization selector so this would be a good extension on that. I suppose the runtime changes could be implemented in a virtual machine... but I don't want programs to rely on memory being set to zero if I then change that mid run...

I like the idea though.

Quote:
Original post by CJM
Just some suggestions. I don't know if any of them are any good, but it's just some stuff that may be useful.

Thanks for the great suggestions! You guys are making me think about this in a different way then I had originally planed the language. I am glad I did this.

umbrae

Sep 18, 2005 at 10:45 PM

Quote:
Original post by mongrelprogrammer
Are you refering to C# delegates? This doesn't quite sound like the delegates I am familiar with (being roughly function pointers (over simplification)). Any references on the type of delegates you are talking about?

I used the name I was introduced to the concept through - probably completely wrong. I think the person was talking about C# delegates, but I have no experience in that lamguage.

A delegate can also be used to describe a class that gets all it's methods called for certain events by another 'controling' class, as opposed to a sub-class of the 'controlling' class.

Quote:
I read your page where you talk about delegates and it sounds like an interface or pure virtual class could easily take the place of delegates.

The difference between interfaces (and/or virtual classes) and states (I'll use states from now on) is the state's class can be changed at runtime, each method call from then on will go to a different class... the data will stay the same. It would be possible to create a new class and set all it's properties to the values from the last class... but states are nicer. It's also important for the classes that are states to not have any extra properties and methods... or handle these additions well.

For simplicity I'm not allowing extra methods and properties because it would require extra work in the vm, objects would be changing size.

Quote:
Looks nice :) How far are you along in your creation?

Not far enough, I suffer from wanting to do it all at once... every situation I get to that would be better done with more work and design I take the longer approach. Just loading files is compilcated for me because I'm looking at the big picture (loading single files, loading groups of files, unloading files, un-linking parts of the code fast). I want it dynamic as possible which takes quite a bit of forethought. I find re-factoring messy and hard.

mongrelprogrammer

Author

mongrelprogrammer

Sep 19, 2005 at 8:29 AM

Quote:
Original post by umbrae
A delegate can also be used to describe a class that gets all it's methods called for certain events by another 'controling' class, as opposed to a sub-class of the 'controlling' class.

The difference between interfaces (and/or virtual classes) and states (I'll use states from now on) is the state's class can be changed at runtime, each method call from then on will go to a different class... the data will stay the same. It would be possible to create a new class and set all it's properties to the values from the last class... but states are nicer. It's also important for the classes that are states to not have any extra properties and methods... or handle these additions well.

The functionality you just mentioned could be done by an interface... For example:

class Move {    MoveStateInterface m_state;    public setState(MoveStateInterface a_state) { m_state = a_state; }    public MoveStateInterface getState() { return m_state; }}interface MoveStateInterface {    boolean moveUp();    boolean moveDown();    ...}class MoveUpOnly implements MoveStateInterface {    boolean moveUp() { return true; }    boolean moveDown() { return false; }    ...}class MoveDownOnly implements MoveStateInterface {    boolean moveUp() { return false; }    boolean moveDown() { return true; }    ...}Which allows for the code:Move moveState = new Move();moveState.setState(new MoveUpOnly());boolean move = moveState.getState().moveUp(); // move = truemoveState.setState(new MoveDownOnly());move = moveState.getState().moveUp(); // move = false

Quote:
Original post by umbrae
For simplicity I'm not allowing extra methods and properties because it would require extra work in the vm, objects would be changing size.

By using interfaces as above differing sizes (or even multiple states) are simple.

Quote:
Looks nice :) How far are you along in your creation?

Quote:
Original post by umbrae
Not far enough, I suffer from wanting to do it all at once... every situation I get to that would be better done with more work and design I take the longer approach. Just loading files is compilcated for me because I'm looking at the big picture (loading single files, loading groups of files, unloading files, un-linking parts of the code fast). I want it dynamic as possible which takes quite a bit of forethought. I find re-factoring messy and hard.

Yah - I understand that. It always take me forever to get deep into a project. Do you have a formal language specification finished? Are you using your own parser / lexer or one of the many premade ones?

fur

Sep 19, 2005 at 3:39 PM

What I most dislike about scripting languages, is that everyone keeps making up new ones!! Gah, there's already a million specialized scripting languages available, and a million more general purpose ones! Stop reinventing the wheel!!

samv

Sep 19, 2005 at 4:38 PM

Quote:
Original post by mongrelprogrammer
The functionality you just mentioned could be done by an interface...

If this pattern comes up alot (and it comes up alot in games) it's convenient to have very succinct syntax for it.

Using interfaces, you'll often have to pass a reference to the parent:

class Parent {   State state;   float x,y;//So you will have to add alot of workaround stuff like this:// void Update() { state.Update(this); } }interface State {   void Update(Parent ref_to_parent);}class Wait implements State {   void Update(Parent ref_to_parent) {}}class GoRight implements State {   void Update(Parent ref_to_parent) { ref_to_parent.x++; }}Parent p;p.state.Update(p); //<- cumbersomep.Update(); //<- better

Language support for states is also more efficient. (Just modify one pointer to change states vs. create a new state object, GC the old state object, calling functions adds an additional level of indirection)

Roboguy

Sep 19, 2005 at 6:57 PM

How about pattern matching, optional type inference and variant types?

umbrae

Sep 19, 2005 at 10:33 PM

Quote:
Original post by samv
If this pattern comes up alot (and it comes up alot in games) it's convenient to have very succinct syntax for it.

Yes!

While it's possible to create any functionality in a turning complete language it's good to have constructs for common patterns. It's really up to you to decide what to include.

Groovy is an interesting dynamic language that has quite a few cool features... I really like their 'half-closure' type things.

list l = [2, 3, 4]l.each    print item

I'm implementing them in my language, they replace the need for iterators with a nicer syntax.

mongrelprogrammer

Author

mongrelprogrammer

Sep 20, 2005 at 8:59 AM

Quote:
Original post by fur
What I most dislike about scripting languages, is that everyone keeps making up new ones!! Gah, there's already a million specialized scripting languages available, and a million more general purpose ones! Stop reinventing the wheel!!

As I said before - this is a research project. Which means that elements of the compiler are novel and unique. But why does that matter? If anyone wants to have the experience of writing a compiler who are you to call them down on it?

--fur++everyone else who posted

Troll.

Quote:
Original post by samv
Quote:
Original post by mongrelprogrammer
The functionality you just mentioned could be done by an interface...

If this pattern comes up alot (and it comes up alot in games) it's convenient to have very succinct syntax for it.

Using interfaces, you'll often have to pass a reference to the parent:
*** Source Snippet Removed ***

Language support for states is also more efficient. (Just modify one pointer to change states vs. create a new state object, GC the old state object, calling functions adds an additional level of indirection)

Well - with some snazzy templates and superclasses instead of just interfaces much of that functionality could be approached. But I see your point. I was trying to find out if I was missing anything technically but you pulled me back to the point of something like this - simplicity.

Still not sure I agree they should be included in a langauge - but I can see how they could be useful to a set of people.

Quote:
Original post by Roboguy
How about pattern matching, optional type inference and variant types?

Type inference is already planned (as it is a simple extension of the type checker). Variant types I am a bit on the fence about. I think they would be a good feature... but I question how much they would be used.

Pattern matching is really something I see as a library level tool - not a language level tool. Though, as was suggested further up the thread, if there was complete freedom to create operators there is no reason that a library level construct couldn't create something that looks built in. I would agree pattern matching should be included - just not sure at what leve.

Quote:
Original post by umbrae
Quote:
Original post by samv
If this pattern comes up alot (and it comes up alot in games) it's convenient to have very succinct syntax for it.

Yes!

While it's possible to create any functionality in a turning complete language it's good to have constructs for common patterns. It's really up to you to decide what to include.

But there is another issue - if you can syntatically create the same style. I think with this state issue normal OOP is capable enough. You are right though - if a pattern comes up alot it makes sense to have a special case of syntax for it. I am just not convinced there is really need for it within the three people who will actually end up using the language (me, myself, and I) :P

If people actually did use it and wanted that feature I suppose I would add it. But for now I am going to leave it out based on my own desires.

Quote:
Original post by umbrae
Groovy is an interesting dynamic language that has quite a few cool features... I really like their 'half-closure' type things.
list l = [2, 3, 4]l.each    print item
I'm implementing them in my language, they replace the need for iterators with a nicer syntax.

I looked over that page - it is an interesting looking language. I have a feeling my evening will be spend browsing around there :P

Again - I appriciate all those who wrote in with ideas (or reasons I should like the states idea). Thanks!

fur

Sep 20, 2005 at 3:44 PM

Quote:
As I said before - this is a research project. Which means that elements of the compiler are novel and unique. But why does that matter? If anyone wants to have the experience of writing a compiler who are you to call them down on it?
--fur++everyone else who posted
Troll.

You didn't say that the research project was to make a scripting language. I assumed the scripting language was just a part of a greater whole, in which case I will always stand by not re-inventing the wheel.

Nice to see folks are allowed to present differing opinions.. not!

Roboguy

Sep 20, 2005 at 3:58 PM

Quote:
Original post by mongrelprogrammer
Quote:
Original post by Roboguy
How about pattern matching, optional type inference and variant types?

Type inference is already planned (as it is a simple extension of the type checker). Variant types I am a bit on the fence about. I think they would be a good feature... but I question how much they would be used.

I would make the type inference optional, if you aren't planning to already. If it isn't, I doubt you could have adhoc polymorphism. Variant types seem to be used quite a bit in languages that have them (my Ocaml project, for example, uses them in it's lexer and parser).

Quote:

Pattern matching is really something I see as a library level tool - not a language level tool. Though, as was suggested further up the thread, if there was complete freedom to create operators there is no reason that a library level construct couldn't create something that looks built in. I would agree pattern matching should be included - just not sure at what leve.

By 'pattern matching' I mean Ocaml- or Haskell-style pattern matching, not like regular expressions. Like this:

type color = Red | Black;;type suit = Hearts | Diamonds | Spades | Clubs;;let suit_color s =  match s with    | Hearts    | Diamonds -> Red    | Spades    | Clubs -> Black;;

or:

let rec map f l =  match l with    | (x :: xs) ->      (f x) :: (map f xs)    | [] ->      [];;

mongrelprogrammer

Author

mongrelprogrammer

Sep 20, 2005 at 4:14 PM

Quote:
Original post by Roboguy
I would make the type inference optional, if you aren't planning to already. If it isn't, I doubt you could have adhoc polymorphism. Variant types seem to be used quite a bit in languages that have them (my Ocaml project, for example, uses them in it's lexer and parser).

By 'pattern matching' I mean Ocaml- or Haskell-style pattern matching, not like regular expressions. Like this:
... code snipped ...

Type inference would only be used for things left untyped. By specifically typing everything there would be no problem with adhoc polymorphism. Very good point though.

Sorry - I missunderstood what you meant by pattern matching. I supposed you would have said regular expressions if that is what you meant :P

I like the idea of including pattern matching - though I would have to think about how to best implement it. I must admit I haven't thought about processing things like haskell's patterns before and they aren't quite the same as the inferences I am more used to in Prolog.

I will have to look into how this would fit into what I already have done. Thanks for the comment :)

Dobbs

Sep 21, 2005 at 9:47 PM

Meta-programming. Something like Lisp macros would be ideal, but I've also heard good things about Ruby blocks (haven't had a chance to play with it much).

Multi-methods

Easy linking to C++ would be nice

And if you're going to include lambda/anonymous functions, for god's sake don't make them as stupidly broken as in Python and PHP.

snk_kid

131

snk_kid

Sep 23, 2005 at 3:40 PM

This is would be nice [grin]:

full asymmetric coroutines

Coroutines & Continuations as first class entities

modules as first class entities

functions as first class entities

Support for generic programming, concept & concept checking.

Concepts as first class entities

Powerful reflection capabilities (both static & dynamic)

closures, lambda expressions, heavy type inference, pattern matching

multimethods (Multiple/Predicate dispatching)

Generic functions (something like Common lisp's generic functions)

I know there is more i just can't think at the moment, i'll probably add some more later on.

flangazor

106

flangazor

Oct 6, 2005 at 7:07 AM

Turing incompleteness. Or sandboxed turing completeness (like how Monads sandbox side effects in Haskell). This should hopefully make programs in your language halt-solvable.

Edit: Charity project: thesis.

[Edited by - flangazor on October 8, 2005 4:07:25 AM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.