MiniD dsource project set up

[Jarrett Billingsley]

"James Dunne" <james.jdunne at gmail.com> wrote in message 
news:e7p9b3$1cps$1 at 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.

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

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

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

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

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

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

It would be TERRIBLE to have generics in a scripting language ;)