Can we make the whole D running interpreted or something just-in-time compile?

"Jarrett Billingsley" <kb3ctd2@yahoo.com> дÈëÏûÏ¢ÐÂÎÅ:e7ngne$a46$1@digitaldaemon.com...
> Link: http://www.dsource.org/projects/minid
>
> == What is MiniD? ==
>
> MiniD is a statically-typed, object-oriented scripting language based on D and designed with D in mind as the host language.  It takes some features from other scripting languages as well, such as static closures, generators, and coroutines.  One of the main ideas behind making it D-based is an almost seamless integration of scripting into the host program, so that native code can very easily call script code and vice versa.
>
> == How far along is it? ==
>
> It's mostly just a grammar and some language specs right now; however, there's a reference compiler in the works which does the lexical and syntactic passes, and has the beginnings of the semantic pass as well.  It can be found into the repo.
>
> == Is it open?  Licensing? ==
>
> It's open.  Licensing?  It could be public domain for all I care.  If some of you more experienced OSS'ers have some comments on that, or if I should use something else (like zlib or MIT license), I'd like to hear it.  In fact, if someone wanted to bring it up on the MiniD forum on dsource, that'd be great.
>
> The development is also open.  I'd love to hear any ideas and suggestions for features and other areas of development.
>
> == Why MiniD? ==
>
> It started as a sort of for-fun project, but eventually developed into something of a learning project.  I wanted to see what it was like to design and implement a compiler and VM.  Maybe I'll end up with a language that people want to use; maybe not.  In any case, it's my idea that perhaps by offloading things like typechecking into the compiler, the VM will be somewhat faster.  Maybe.  I hope :)
>
> 

"Boris Wang" <nano.kago@hotmail.com> wrote in message news:e7q6kq$aq7$1@digitaldaemon.com...

> Can we make the whole D running interpreted or something just-in-time compile?

MiniD is not a scriptable D; it's just a scripting language that looks like D.  You'll have a native host program, most likely written in D, which will load MiniD code (either source or compiled into bytecode) and run it.  JIT compiling is a little over my head :S

Jarrett Billingsley wrote:
> "clayasaurus" <clayasaurus@gmail.com> wrote in message news:e7pa43$1f94$1@digitaldaemon.com...
> 
> 
>>If you use zlib/png license, then you can freely borrow code from the Squirrel project (with acknowledgment of course), and commercial applications can freely use it. :)
> 
> 
> Cool, thanks for the tip.  I'm not real familiar with all the licensing that usually goes along with OSS. 
> 
> 

I've been using the Artistic License 2.0 for some things, and rather like it.
http://dev.perl.org/perl6/rfc/346.html

The zlib/png license is good too, however.  Personal taste will probably decide it.

On a side note, I rather like the look of the language, and do appreciate a very D-ish feel.  I might just try to use it in some projects in the future once you get a referance implementation together.

-- Chris Nicholson-Sauls

Jarrett Billingsley wrote:
> "James Dunne" <james.jdunne@gmail.com> wrote in message news:e7p9b3$1cps$1@digitaldaemon.com...
> 
> 
>>1) Fix /wiki/LanguageSpec/Lexical section after Tokens, a sentence is broken.
> 
> 
> I'd fix it but I can't find any broken sentences.  Perhaps you meant the second sentence?  Maybe I should put quotes around the "...", since that means the D vararg token.
> 
> 

Yeah that was it.  It just parsed weird in my brain.

>>2) With the escape sequences in string literals, how would I go about putting the number one after an ASCII character #1? \11?
> 
> 
> \0011 - The decimal escapes can only be three characters long, so it will suck up \001, and then the next 1 will be the next character.
> 
> 

I completely forgot about 0 padding.  Still, it's weird and wasn't intuitively obvious to me (obviously). ;)

>>3) Good to see the ability to define binary integer literals; they're immensely useful
> 
> 
> I've found them to be as well :)
> 
> 
>>4) Multiple setter functions allowed for properties (and seem to be required to have at least one) but only one getter function is allowed and is optional?  Why is this?
> 
> 
> Setters are optional, but multiple are allowed.  I'm also thinking of enforcing the rule that if there are any setters, at least one must take the same type of the property (so if you have an int property, and you have setters, there must be one that takes an int, but all the rest can be whatever).  You can only have one getter because of function overloading - getters are defined as something like "<proptype> __get()", and of course you can't overload based on return value.  It's optional in case you need a write-only property (for whatever reason).  So you can have read-only properties by only having a getter; write-only by only having setters; and read/write by having both.
> 
> 

Okay, I see now.  I was thinking in terms of indexors as properties, like myobj.a[3] = 4; and a = myobj.b[6,7], etc.

>>5) Regular assignment on /wiki/LanguageSpec/Expressions:  Is it a good idea to treat x = obj.prop = 4; as two separate expressions?  You're sort-of violating the general rule to not evaluate the property more than once.  Why not have the implementation of the setter functions return the value that was set?
> 
> 
> I'm not real fond of that either, and that part might change.  I suppose it'd be fine to allow property setters to return values so you can chain property assignments like this, but _personally_ I find assignment chaining to be in _bad taste_ ;) and so might disallow chaining property assignments altogether.  But that might be a little too draconian for some people.
> 
> 

Yeah I also find myself avoiding chained assignments, but I don't know why.  I guess I like to limit the horizontal span of my code.  It's much easier to scroll vertically (go mouse-wheel!) than it is to scroll horizontally. :)

>>6) Operation assignments: you don't state that you're going to check for the same setter/getter function call signature for a property, you just say that the property must have them both set.
> 
> 
> If a writeable property is enforced to have one setter that takes the same type as the property as mentioned above, then this can work.
> 
> 
>>7) So custom defined objects cannot be passed in varargs functions?
> 
> 
> No, they can - you use the .asObject() member of the vararg and then cast down to your class type.  All classes will inherit from Object, like in D (yet to write the class spec).
> 
> 
>>I would recommend renaming 'def' to 'local', just as it's more aesthetically pleasing to me.
> 
> 
> I tried local, but then that doesn't make sense for global variables.  I wanted something short and unambiguous.  'def' seemed to fit the bill, despite being a bit .. reminiscient of Lisp?  Oh well, it ended up being Python-esque anyway.
> 
> 

Oh yeah, the globals - I always forget about the globals...  They're local to the global scope, yes?

>>Also, why do you have the 'def' keyword as the starter to function parsing in addition to global variable parsing, would you not use a separate keyword 'function' for that?
> 
> 
> 'def' begins all variable and function definitions except for function parameters where it's unambiguous what's expected.  I did acually have "function" start function declarations before, but with functions that _returned_ functions, it started getting really funny-looking:
> 
> function void function() foo() { }
> 
> I also had some grammar ambiguities when using "function" to begin functions when dealing with function literals.  As of now, "function" is _just_ used for the type, and it's nice that way.
> 
> 

How about switching to a Pascal-inspired declaration syntax in combination with the 'function' keyword:

function max(x,y : int) : int {
	return (x < y) ? y : x;
}

function hello(a, b : int) : function(c,d : int) : int {
	return max;
}

Reads nicely left-to-right.

>>It would be nice to have generics implemented in a scripting language :)
> 
> 
> It would be TERRIBLE to have generics in a scripting language ;) 
> 
> 

LOL - you don't get more disagreeable than that.

Overall, I like your idea!  A D-looking script language that's easily embeddable in a D host program really makes it easy on the developer. Just don't put in too many 'gotchas' that would deviate far from the original D.

-- 
Regards,
James Dunne

Jarrett Billingsley wrote:
> "Boris Wang" <nano.kago@hotmail.com> wrote in message news:e7q6kq$aq7$1@digitaldaemon.com...
> 
> 
>>Can we make the whole D running interpreted or something just-in-time compile?
> 
> [snip]
> ...  JIT compiling is a little over my head :S 
> 
> 

With that attitude it always will be...

-- 
Regards,
James Dunne

Hi,

> I guess there's not much use to make yet another scripting language unless it's a for-fun project. You might want to try Ruby. It has many features in common with D. I'm not sure if someone has already made an attempt to implement a Ruby interpreter in D.

Not exactly interpreter, but a bridge from myself:

untested beyond myself, might require special ares/phobos mix, not for the faint of heart.

For support, you can ask me, don't expect too much though. License is unspecified. Do with it what you want (it probably won't work for you anyway, if it does, great).

Kash

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

"James Dunne" <james.jdunne@gmail.com> wrote in message news:e7qdqp$k3m$1@digitaldaemon.com...

> Okay, I see now.  I was thinking in terms of indexors as properties, like myobj.a[3] = 4; and a = myobj.b[6,7], etc.

I was originally toying with the idea of namespaces for properties which would hold special functions like opSet and opGet, and then could also hold things like opIndex[Assign] and opSlice[Assign].  That started getting a little complex, but I suppose some special functions could be allowed in the property blocks, such as

property int x
{
    def int opIndex(int index)
    {
        return mArray[index];
    }

    def int opIndexAssign(int value, int index)
    {
        return mArray[index] = value;
    }
}

...

def A a = new A;
a.x[5] = 4;
io.writefln(a.x[5]);

It could work.  It's something that I always wanted in D - the ability to easily wrap an array in a class, allowing access to the members but to nothing else (so the user couldn't resize, sort, delete etc. the array).

> Yeah I also find myself avoiding chained assignments, but I don't know why.  I guess I like to limit the horizontal span of my code.  It's much easier to scroll vertically (go mouse-wheel!) than it is to scroll horizontally. :)

I always follow the mantra of one statement per line.  That's partly why you can't have multiple variable declarations on one line, and also why there's no postfix ++ and -- (since IMO they cause nothing but confusion).

> Oh yeah, the globals - I always forget about the globals...  They're local to the global scope, yes?

Mmmmmm..... maybe.  ;)

> How about switching to a Pascal-inspired declaration syntax in combination with the 'function' keyword:
>
> function max(x,y : int) : int {
> return (x < y) ? y : x;
> }
>
> function hello(a, b : int) : function(c,d : int) : int {
> return max;
> }
>
> Reads nicely left-to-right.

Huuhh.. I've seen that kind of mix of C and Pascal before, and I'm not entirely fond of it.  It does certainly make parsing declarations much easier.

> LOL - you don't get more disagreeable than that.

Yeah, templates scare me a bit.  Especially something as complex as D's templates.  Perhaps very simple generics could work (basically just allow templated classes / functions, with simple specialization), but that'd be something for MiniD 2.0 ;)

> Overall, I like your idea!  A D-looking script language that's easily embeddable in a D host program really makes it easy on the developer. Just don't put in too many 'gotchas' that would deviate far from the original D.

I'll try not to.  Most of the things I'm changing are simply removing more complex features, while trying to keep the rest as close as possible.

"James Dunne" <james.jdunne@gmail.com> wrote in message news:e7qdv5$k3m$2@digitaldaemon.com...

> With that attitude it always will be...

Oh foo!

In article <e7q97v$e04$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>"Boris Wang" <nano.kago@hotmail.com> wrote in message news:e7q6kq$aq7$1@digitaldaemon.com...
>
>> Can we make the whole D running interpreted or something just-in-time compile?
>
>MiniD is not a scriptable D; it's just a scripting language that looks like D.  You'll have a native host program, most likely written in D, which will load MiniD code (either source or compiled into bytecode) and run it.  JIT compiling is a little over my head :S
>

A few years ago, when I was dreaming to make my own little programming language,
I've seen the libjit library :
http://www.southern-storm.com.au/libjit.html

(I am still dreaming now, but I have more ideas of how to do it.)
I know very little about it. There is a C interface and it aims to be portable.

Native code generation is not the only way to optimize a bytecode program : I've heard about some Smalltalk variant that was not using the 256 bytes possible to code the bytecode instructions. The remaining bytes where used to create macro instructions.

The bytecode was first analysed, the bytecode sequences that was appearing frequently where detected and kind of precompiled into a macro instruction wich number was placed in the available bytes. Then, the bytecode was reduced : the sequences where replaced with their corresponding macro numbers.

The program sized was shorten and the macros allowed to reduce the amount of lookup and stack frame to be used and made the program more efficient/fast.

"Rémy Mouëza" <ray.jay.ay.moueza@DoNtSpAm.gmail.com> wrote in message news:e7ruk6$2o5n$1@digitaldaemon.com...

> A few years ago, when I was dreaming to make my own little programming
> language,
> I've seen the libjit library :
> http://www.southern-storm.com.au/libjit.html
>
> (I am still dreaming now, but I have more ideas of how to do it.)
> I know very little about it. There is a C interface and it aims to be
> portable.

Wow; that library looks amazing.  I'll definitely keep it in mind!  It certainly doesn't look very difficult to use.