SimpleScript Part Seven: Binder Skeleton

re: SimpleScript Part Seven: Binder Skeleton

John — Mon, 07 Sep 2009 08:27:31 GMT

Hi Eric,

I am aware of the fact that more than 4 years have past since this blog entry was made, but I would love to get my hands on the source code attached to this post. Our product uses the msscript.ocx server-side in order to execute user-defined vbScript's - since there has not been a 64-bit release we need to consider our options for backward-compatibility whilst at the same time trying to be 64-bit compliant. Do you know by any chance whether or not a 64-bit replacement will be released? Who can I ask for other (backward-compatible) options (next to Dr. Google which has not been much of a help, except for finding your blogs:)).

Any plans for a vbScript.NET or even a IronVbScript? ;).

VBScript Default Property Semantics

Fabulous Adventures In Coding — Tue, 30 Aug 2005 20:43:13 GMT

Here’s a question I recently got about VBScript, where by "recently" I mean August 28th, 2003.&nbsp;This...

VBScript Default Property Semantics

Fabulous Adventures In Coding — Tue, 30 Aug 2005 20:43:00 GMT

Here’s a question I recently got about VBScript, where by "recently" I mean August 28th, 2003.&nbsp;This...

re: SimpleScript Part Seven: Binder Skeleton

Eric Lippert — Mon, 10 May 2004 18:18:00 GMT

Thanks Nicholas. I think you're right on the money.

I've never written a copy-based GC before, so that might be an interesting experiment. And I agree that a goal of the language should be brevity.

I once considered writing up a .NET language that I was going to call "VERBOSE" -- basically a simple C#-like demonstration language but with the property that there were NO optional keywords. A typical class declaration would look something like

class {
name := "MyClass",
sealed := true,
extends := class {
name := "MyBaseClass",
namespace := "MyNamespace"
},

etc, etc. It would have been wonderfully horrid. I never did get around to it though.

I agree that the runtime is the interesting part, but I will probably concentrate upon the infrastructure -- the GC, the error reporting mechanism, etc -- and not implement things like a big string manipulation library, a date object, etc.

Pedagogy

Nicholas Allen — Sat, 08 May 2004 18:28:00 GMT

Since I promised earlier to write more on this I thought I'd catch up.

There seems to be three big tradeoff areas to consider:

Scriptyness- how well the language supports quick, little programs
Parser complexity- how hard the language is to process
Runtime complexity- how hard the language is to execute

In general, scripty languages are harder to parse and run (automatic semicolonization, expando objects). We can trade parser and runtime complexity by moving things like type checking to be early or late (which also impacts the scripty feel). These choices affect other "cool stuff to do" items. Syntax coloring needs to match the parser and debugging needs to understand the runtime.

There's a minimum level of scriptyness required. Fortran77Script#.NET really just misses the point. I think though that complex scripty features are better described than implemented. Slotted objects are neat but you wouldn't want to read the code that handles them after the preprocessor has gotten done with it. My goals are:

* Eliminate boilerplate and uninteresting code. Make a language that lets you do a two line job in two lines.
* Support programs more interesting than "Hello world", less interesting than being able to compile itself

I consider the parser the least interesting part. There are a lot of good books on how to parse just about anything. As long as the parser works and it's not too hard to add new language features that's fine by me. There will probably be a lot of questions about code generation which is not as commonly talked about. And that leads to...

The runtime which I consider the most interesting part. There are two ways to go here. The first is to develop a new runtime which would explain a lot about memory management, call resolution, and how existing languages are implemented. There have been only a few good discussions like this. The second is to leverage an existing runtime. I've never seen a really detailed look going through the entire process. The original roadmap had Managed Code - ? so maybe.

GC

Trevor Talbot — Fri, 07 May 2004 12:26:00 GMT

My main interest here is in the script engine interfaces; I'm coming from a perspective of wanting to implement an engine for an existing language. In this case I want to know what the engine needs to be aware of for a GC'd language, but the actual GC may as well be a black box. I just need to know how my language behaves.

On the other hand, I'm interested in GCs for separate reasons. One of the most intriguing things to me is the ability to move memory, for better locality, larger allocation, or whatever. This is also more interesting because it requires awareness of the language -- what a memory reference is, etc. So if you do decide to explore a complex GC, I echo Nicholas' comments in that I'd like to see a good stepping stone for experimenting with more exotic things.

re: SimpleScript Part Seven: Binder Skeleton

Eric Lippert — Wed, 05 May 2004 05:50:00 GMT

Re: IID_NULL -- Hmm, I'm surprised the compiler didn't catch that. Looks like I need to bump the warning level up to max.

Re: Two to's is too many. Yep.

Re: LError on non-error. Yeah, you're right. I might fix that up.

re: SimpleScript Part Seven: Binder Skeleton

Eric Lippert — Wed, 05 May 2004 05:48:00 GMT

Re: failing to provide room -- it's possible that the property get has a side effect and you care about that, not the return value. That's a very rare situation, but it is legal.

re: SimpleScript Part Seven: Binder Skeleton

Nicholas Allen — Wed, 05 May 2004 03:01:00 GMT

// Failing to
// provide room for the return value is dumb, but not illegal.

Arrgh.

Binder::Invoke sure was a lot of fun to read.

re: SimpleScript Part Seven: Binder Skeleton

Nicholas Allen — Wed, 05 May 2004 02:57:00 GMT

Binder::GetIDsOfNames >>>
if (IID_NULL != riid)
{
return hr= DISP_E_UNKNOWNINTERFACE;
goto LError;
}
<<<

This probably isn't what you wanted to do.

Binder::Invoke >>>
Bug("We don't support named arguments to except to property puts.")
<<<

Too many to's here.

The goto LError; kind of bugs me. It makes a lot of sense when there actually is an error. But it's also used to skip to the end of a function even when everything is ok. I'd be quicker to understand what you were doing if it was goto out; on success or something.

>>>
HRESULT GetIdOfName(const WCHAR * pszName , DISPID * pdispid);
HRESULT GetNameById(DISPID dispid, Name * * ppName);
<<<

Interesting that these aren't symmetric.