# New version of KScript Editor



## kotori (Dec 19, 2010)

Hi everyone,

There is now a new version of KScript Editor. :arrow: *Download*.

Change log:
 Support for all new Kontakt 4.2 (beta) variables and functions.
 Support for "on listener" callback and ui_waveform controls.
 Fixed a bug that caused some unused "call":ed functions to not be removed. Which could create errors claiming there were undeclared variables in case those functions declared local variables.
 Recursion detection improved for functions invoked using "call"
 When the "Compact variable" option is active the program keeps a reverse lookup table for the last compiled script in RAM. This is used to present error messages in uncompacted form.
 There is a new option in the Script menu to "uncompress" code where the variable names have been made compact. This can be used when Kontakt reports an error that KScript Editor does not catch. You can then copy the compacted code from Kontakt and use this tool to make it readable, thereby making it easier to locate. The reversal only works if you just before that compiled that script from source. It cannot be used to "break" the compaction scheme of a script for which you do not have the source code.
 When the "optimize compiled code" setting is active the program no longer removes unreferenced variables if they are UI controls.
Cheers,
Nils


----------



## Dynamitec (Dec 20, 2010)

Thanks a lot Nils!  o=<


----------



## Dynamitec (Dec 20, 2010)

Well, funny thing. I had to turn of UAC and restart my PC to install the new version of the KSCript editor. I found some variables which are missing in that update.

$NI_SIGNAL_TRANSP_STOP
$NI_SIGNAL_TRANSP_START
$NI_SIGNAL_TIMER_MS
$NI_SIGNAL_TIMER_BEAT
$NI_SIGNAL_TYPE
$NI_CALLBACK_ID
$NI_CALLBACK_TYPE
$NI_CB_TYPE_NOTE
$NI_CB_TYPE_RELEASE
$NI_CB_TYPE_CONTROLLER
$NI_CB_TYPE_POLY_AT
$NI_CB_TYPE_INIT
$NI_CB_TYPE_UI_CONTROL
$NI_CB_TYPE_UI_UPDATE
$NI_CB_TYPE_PGS
$NI_CB_TYPE_MIDI_IN
$NI_CB_TYPE_RPN
$NI_CB_TYPE_NRPN
$NI_CB_TYPE_LISTENER


----------



## kotori (Dec 20, 2010)

I have now added those missing variables to both the PC and Mac version. Thanks Benjamin.


----------



## Dynamitec (Dec 20, 2010)

That's support one can dream of  Thanks as always!

And a suggestion to all scripters here, who work on commerical libraries (or do scripting just for fun): don't forget the PayPal-Donation button on Nils homepage. I think it's amazing that we get such a great tool for free and that Nils is constantly improving the editor. Let's support that!


----------



## jamwerks (Dec 20, 2010)

What could this do for my poor Westgate Horn samples ?


----------



## kotori (Dec 20, 2010)

Thanks Benjamin  

Donations are indeed welcome (see the link on the   ã   ®  ã   ®o  ã   ®4º  ã   ®53  ã   ®7  ã   ®7_  ã   ®JŠ  ã   ®J¯  ã   ®[  ã   ®[e  ã   ®nû  ã   ®o(  ã   ®Ã  ã   ®×  ã   ®“m  ã   ®“‚  ã   ®–›  ã


----------



## Reegs (Dec 20, 2010)

Thanks for the update Nils!

I really, really like the idea of implementing set and get params as pointers. That would be so cool!


Reegs


----------



## sonaht (Dec 20, 2010)

Hi Nils,

Just sent a paypal payment your way. More is coming to other contributors of this community as I am learning tons more than I am able to contribute and give back at the time.

Happy holidays!

Thanos


----------



## kotori (Dec 21, 2010)

Thanks a lot to those of you who made donations. I will not post the names here in order to not put any public pressure on anyone since I want everyone to feel that it is completely optional to contribute, but that does not mean that I'm any less grateful. A big thanks to you - much appreciated. :D


----------



## kotori (Dec 21, 2010)

Btw. maybe I could take the chance to discuss some possible future directions for the compiler. First off I received a PM from Blake where he mentioned some ideas of his. I trust that it's ok to post a copy here. I will add some of my thoughts about this and invite everyone to add comments to this and my next post.


> ui controls having properties that substitute with set_control_par or get_control_par - eg:
> declare ui_control $button
> $button.top_x := 5
> $button.top_y := 1
> $button.picture := "blahblah"


I really like this and had some similar plans myself. Using a "." character before the property name could potentially pose some problems for the compiler design, but if that's the case I guess one could always use another operator like eg. "$button->top_x := 5".



> control arrays that would work with the properties
> declare ui_button $button[5] {would also create a %ui_button array to store ids}
> for $i := 0 to 5
> $button[$i].top_x := $i * 20 {would do set_control_par(%ui_button[$i], ....) }


I'm slightly sceptical to, although not completely against, this declaration syntax. If one needs say 40 buttons it's quite easy to declare them in a function in a separate module (maybe the editor part of KScript Editor could provide some tool to make this even easier). That way they don't clutter the source code. If they are explicitly declared the user also has a choice of whether to rely on the UI IDs being consequtive and initialize them in a loop or to initialize them with one get_ui_id line for each control.

I am against the "$button[$i].top_x" syntax since it feels inconsistent to have an array with $ prefix. Instead I think it could be nice if the compiler when seeing for example "$x.picture" could check whether $x is a ui control or not and based on that decide whether to use get_ui_id($x) or treat $x as a UI ID. If one were to write "%buttons[$i].top_x" the compiler would then notice that "%buttons[$i]" is not a UI Control and hence treat it as a UI ID.



> quick way to declare control arrays, eg:
> declare ui_button $button, $button2, $button3
> declare ui_label $label (1,1), $label2 (2,1), $label3 (1,1)


To me this doesn't seem to give enough advantage over declarations on separate lines to merit a syntax change, but I'm not sure I completely understand the thought behind this.



> declares inside callbacks/k4 functions moved to on init and prefixed with callback name, eg:
> function test
> declare $i
> end function
> ...


Yes, this is something that I have wanted to do for a long time. It should be easier if I can get this new implementation for the first compilation phase working.



> inline defines, eg:
> for define $i := 0 to 10 {would move define to top, and if in a callback to on init with callback name prefix)


Yes, that could indeed be nice, but I think "declare" would be more consistent than "define".



> multidimensional array declaration, eg:
> declare %array[10][10] {becomes %array[10 * 10]}
> %array[7][1] := 5 {becomes %array[(7*10)+(1)] := 5}


I agree about this. 



> quickform version of get_ui_id, eg:
> declare ui_button $button1
> declare ui_button $button2
> declare %buttons[2]
> ...


Spontaneously I'm against this. If the compiler supports return values for user-defined functions it's easy enough to create a shorter alias for get_ui_id. One could then write "%buttons[0] = id(button1)". Alternatively one could perhaps use a variation of the property idea above and use the syntax "%buttons[0] = button.id".



> support for setting strings on declare
> declare @string := "blahblah" {splits it into two lines on compile}


That's indeed natural to support.



> byte-strings support, adding a new type of custom string object that can be compared and processed, eg:
> declare @@newstring[64] {replaced with declare %newstring[64]}
> @@newstring := "abcdefg" {replaced with %newstring[0] = 97 %newstring[1] = 98 %newstring[2] = 99, etc}


I'm not favor of this idea because it seems to impose some specific design decisions on the compiled code. For example, if the strings are long enough that it would be logical to use a for loop for initialization or if you wanted to store all strings in a global string array and keep offsets to the start and end of each string, what would you do then?

If this feature is needed I think it would be better to not change the syntax but rather add this in the form of some special functions that the compiler could inline in a suitable way, eg. 'set_string(%text_letters, "abcdefg")'. 



> ability to import text strings from file delimited by \n's, eg:
> declare !fileimport
> !fileimport := __filetostrings("c:\blahblah.txt")


It doesn't strike me as tremendously useful, but generally I'm much more open to the addition of special functions than changes to the syntax, which I think should be kept to a minimum. In that sense I'm probably inspired by the Python programming language which is powerful but yet has a very simple syntax. I also want the extended KSP syntax to stay as true as possible to the standard KSP syntax.


----------



## kotori (Dec 21, 2010)

Here is an example of how I plan for return values to work in a future KScript Editor compiler version:

_{ Multi-line function }_
*function* min(a, b) -> result
``*if* a < b
````result := a
``*else*
````result := b
``*end if*
*end function*

_{ Single-line function }_
*function* id(control) -> result``
``result := get_ui_id(control)``
*end function*

*on init*
``*declare* ui_slider myslider(0, 100)``
``
``_{ Multi-line functions can only be used as the single expression in the right hand side of an assignment.
Under the hood the left hand side (myslider in this case) is effectively passed as a kind of parameter,
and the compiler replaces any occurances of the result variable by myslider. }_
``myslider := min(4, 10)``
``
``_{ Single-line functions can be used anywhere in expressions }_
``message(get_control_par(id(myslider), CONTROL_PAR_VALUE))
*end on*

The code above would compile into:

```
on init
  declare ui_slider $myslider(0, 100)
  if (4<10)
    $myslider := 4
  else
    $myslider := 10
  end if
  message(get_control_par(get_ui_id($myslider),$CONTROL_PAR_VALUE))
end on
```

Maybe it would be nice to support multiple return values in the multi-line case too, but I haven't made any decision on that yet. In that case one could perhaps write "$x, $y := myfunc(...)".

Comments and suggestions are welcome.

Cheers,
Nils


----------



## Big Bob (Dec 23, 2010)

Hi Nils,

It all sounds wonderful to me. Unfortunately I haven't had a chance to come up to speed yet with K4 so I can't participate too intelligently at this point, but, maybe soon now I hope.

In any case let me wish you and all the 'VI Controlites' a very Merry Christmas.

Bob


----------



## kotori (Dec 25, 2010)

Hi Big Bob,

Always good to see you around. A Merry Christmas to you too.

Nils


----------



## Big Bob (Feb 23, 2011)

Hi Nils,

Would it be difficult to provide some mechanism to support functions with a variable number of parameters? I forgot what this is called, maybe overloading or something like that? No, I guess overloaded functions probably refer to multiple behaviours based on the number of parameters passed or something like that :oops: 

Anyway, what I'm thinking about is a general parameter passing wrapper for ksp functions. For example, if we were to implement a 'thread-safe' stack frame mechanism for local variables and parameter passing, it would be nice if we could write a KScript wrapper function that could accept a variable parameter count rather than writing a bunch of variants to handle 1, 2, 3, or N parameters for instance.

I guess you would need some way for the function to communicate the total number of parameters and some way to refer to them by their position rather than by name. At least for now, I'm thinking of simple integer parameters, not arrays or strings, etc. Sort of a limited call by value scheme instead of any kind of call by name scheme.

Have you given any thought to some way to provide local variables and parameter passing for ksp functions? I think we could solve the thread-safe problem by using a separate set of stack frames for each parallel process by leaning on the callback id.

Of course the whole thing might be more work than its worth and probably as soon as we got it working, NI would release K5 with real user functions anyway :lol: 

Just sort of thinking out loud. You have a great day my friend.

Rejoice,

Bob


----------



## kotori (Feb 24, 2011)

Hi Bob,

I understand what you mean by overloaded functions, but I'm not sure I understand the use-case you are describing. Would you care to give a small example?
Please note that thread-safety for local variables is only important for functions that directly or indirectly invoke the wait function. In my experience that's a small minority of all functions.

Cheers,
Nils


----------



## Big Bob (Feb 24, 2011)

Hi Nils,

After re-reading my post I realized that it probably was not too well expressed. That's why I tacked on the final statement about 'just thinking out loud' :lol: 



> Please note that thread-safety for local variables is only important for functions that directly or indirectly invoke the wait function. In my experience that's a small minority of all functions.



Very true and that's why I said that this whole thing may be way more work than it's worth. What I'm thinking about doing might be tantamount to using a 'steam roller to snuff out a match'. :roll: However, there are some situations that I have run into, where wait-paced loops are involved and true local variables would neatly solve the problem. So, it might be nice if we had an optional way to create and use thread-safe locals. Sort of a general polyvar that can be used across different callback types and not just note-event tied (and therefore restricted to the NCB/RCB).

Let me spend a little more time on this to organize my thoughts better and then I'll try to drop a more coherent post. Keep in mind that I'm a little rusty and in my zeal to catch up, I may tend to kind of rush around like a bull in a china shop. :lol: 

Rejoice,

Bob


----------



## kotori (Mar 8, 2011)

Hi Bob,

I will try to fix it a future version. Personally I think I have only run into this problem a single time though, so to me it seems like a quite minor problem in the greater scheme of things. The work-around you used is the best one.

Cheers,
Nils


----------



## Big Bob (Mar 10, 2011)

Hi Nils,

I thought the way your editor used to work (with code optimization on) was that 'named' constants were replaced everywhere with literal values and then the constant declarations themselves were eliminated. Is my memory faulty or has this changed somewhere along the line? 

I just noticed, when compiling a script I'm working on, that my constant declarations are still in the compiled source code and, moreover, that each reference appears intact (in its symbolic representation) instead of as its literal numerical value. I haven't tried any earlier versions of your editor because I'm using a lot of the latest K4.2 stuff.

For me this is a real bummer because I have been assuming all along that symbolic constants could be used freely without any penalty. Hopefully this is a simple thing to correct?

God Bless,

Bob


EDIT: This is really weird. I just tried V1.47 with a trivial script and it seems to eliminate the constant declarations properly. Is this problem somehow related to something in my specific script? I'll try to run this done more carefully and repost.


----------



## Big Bob (Mar 10, 2011)

Boy I must have been smoking something I shouldn't have again :lol: 

After I discovered it worked OK with simple test scripts, I edited the script under development by shorting out a major section and recompiling. Then everything worked properly. So, one by one I enabled parts of the shorted out stuff to see when the problem would return. But, I finally got back to the full script and it was still working correctly :shock: 

So, the good news is that I can no longer reproduce the problem, the bad news is I haven't got the faintest idea what happened earlier. Please forgive my false alarm and believe me, I'm really happy that it works like I thought it did because this is a wonderful feature of the KScript editor that I would hate to lose.

And lastly, I know I've said it many times before but, I just can't say enough good things about your editor. I would be most miserable without it. And now that I'm 'back in the saddle' with scripting, I think it's about time for another Pay Pal visit.

You have a great day my friend,

Bob

BTW I've just started to employ native KSP functions and initially I was a little dissappointed with the poor code line savings in most cases. Of course the biggest cause of this is that native functions don't handle parameter passing and by the time you enclose the native function in a KScript wrapper, all the extra variables and assignments involved to get a set of parameters to and from the native function eats up a major portion of the code savings. In fact, in some cases the total lines increase!

But, I've cooked up an 'efficient' parameter passing scheme that looks very promising so far and the reason I mention it is that a few minor enhancements to the KScript editor might really make this process even more elegant and readable. So, after I get it thorougly gelled, I'll repost with some ideas for future enhancements that we can kick around.


----------



## Big Bob (Mar 13, 2011)

Hey Nils,

I have a question about the 'import' directive. It seems like I remember vaguely that, if a function is given a name like on_init, all variables declared within it are considered 'global' unless overidden with a 'local' directive. Could you ( or anyone else with a young brain that still remembers :lol: ) expound upon this a little? 

Thanks,

Bob

EDIT: A quick test seems to confirm the above. However, does this only work with that one specific name 'on_init' or are there other variants that can be used? I guess one can also use any other name by using for example:


```
function my_inz
  on_init
end function

function on_init
   ----
   ----
end function
```


----------



## kotori (Mar 13, 2011)

It's simple: if the function name starts with "on_init" (not case-sensitive) then all variables are implicitly assumed to be global.


----------



## Big Bob (Mar 13, 2011)

kotori @ Sun Mar 13 said:


> It's simple: if the function name starts with "on_init" (not case-sensitive) then all variables are implicitly assumed to be global.



Thanks Nils, I thought it was something easy like that but my old brain just doesn't cooperate sometimes :cry: 

BTW A long time ago, Benjamin posted some requests for some kind of character replacement by the pre-processor. Did anything ever happen with that?

If you ever plan to make another major overhaul of your editor, perhaps you could re-open a discussion about such a feature? It would be very useful to have such a capability, especially if wildcards were allowed.

Rejoice,

Bob


----------



## kotori (Mar 13, 2011)

Big Bob @ Sun Mar 13 said:


> BTW A long time ago, Benjamin posted some requests for some kind of character replacement by the pre-processor. Did anything ever happen with that? (...) It would be very useful to have such a capability, especially if wildcards were allowed.


I'm not sure that I understand what you are referring to. Please be a bit more specific.
If you mean the ability to use macro parameter inlining within strings then that works in the new (yet unreleased) future version of the compiler. If you mean the ability to use for-loops on the preprocessor level then I'm a bit reluctant to implement that since it's nowadays possible to do so much using macros.

Cheers,
Nils


----------



## Big Bob (Mar 14, 2011)

I was hoping that you might remember the original discussion. :lol: Since I haven't been active for a couple of years, my memory is a little dim on the details but the gist of the thing is to have some kind of automatic replacement feature that allows the scripter to use a kind of a shorthand notation for frequently occuring expressions. Benjamin had some suggestions for its capabilities and syntax. I do remember, at the time, when writing larger scripts, I would often run into highly repetitious expressions that I would wish I could write more compactly for clarity and when Benjamin brought up the topic, I jumped in with some limited thoughts.

One example might be something like when reading an engine parameter and then involving the value multiple times in a complex boolean expression. Many of the engine parameter expressions are very verbose owing to NI's use of long, descriptive names. So, suppose one needs to write: if (ep > 6 and ep # 10) or in_range(ep,50,60). Now if ep is a lengthy expression, it would sometimes be very nice if we could somewhere say that ep should be replaced by <a lengthy expression> and then simply write ep each time we need to write the expression. I realize that one could first assign the value to a local variable and then use that variable in the boolean expression, but, let's just say that there are times when one would prefer not to introduce another variable just for such a purpose.

While macros provide a lot of general manipulation of this sort, macros have to be invoked on a line by themselves (or at least I think they do). So, for trivial example, suppose we frequently need to toggle a variable name p between 0 and 1 and we use Nicki's (1 - p) trick. If I need to write some complex expressions using both p and its complement, it might be nice if I could define somewhere that t(p) = 1 - p. Then I could write:

```
if nn[1] > np.note[t(p)] or nn[0] < np.note[p]

instead of
if nn[1] > np.note[1 -p] or nn[0] < np.note[p]
```

I realize that this trivial example wouldn't be of much practical value but I'm just trying to illustrate the general idea of the thing.

If the facility for this was powerful enough, allowing the use of wild cards and such, it might even be used for something like the colon notation I suggested to you in an email. ie replacing something like X:Y with p[$X+$Y].

I'll try to fish out the original thread where we discussed this, because right now I'm not involved in writing any large scripts and I have no actual examples at hand.

I could also benefit from some clarification regarding macro parameters. I notice that something like the following works (in that a constant named Bill.Gates is created).


```
on init
  name(Bill,Gates)
  message(Bill.Gates)
end on

macro name(#first#,last)
  declare const #first#.last := 6
end macro
```

It also works with first,#last# or when using #first# ,#last# but it doesn't work with first, last. I don't know that I ever heard an explanation of under what conditions one needs to use the enclosing # characters. Could you expound on this a bit?

Rejoice,

Bob


----------



## kotori (Mar 14, 2011)

Hi Bob

The first case is already covered by the new function capabilities in the latest compiler version (which is yet not integrated into the latest KScript Editor release). One simply defines a one-line function like this:

*function* t(p) -> result
``result := 1-p
*end function*

These are functions though, so they don't support parameters using # like macros do. It may be possible to make macros useable also inside expressions, but it's not that easy considering the way it's implemented right now. 

Addressing the second point, function parameter substitution works like this:
when the compiler encounters a variable it looks at the part up until the first dot ("." character) or to the end if there is none. In the case of foo.bar this would be "foo" and in the case of foo it would be "foo" too (since there is no dot). If this part matches a parameter name then this part is replaced by the parameter value. So if "myfamily" is passed as parameter foo to the function, then foo.bar would be replaced by myfamily.bar. However, a hyptothetical reference to the variable foobar wouldn't match and would remain unchanged. This is where you can go further with the macro parameter names using #. If there is a #foo# parameter whose value is myfamily, then #foo#bar would be changed to myfamilybar - unlike what happens in the previous case. I hope this answers your question.

Cheers,
Nils


----------



## Big Bob (Mar 14, 2011)

Hi Nils,

That's good news about function's returning values. Do you have a rough idea when it will be released for us to play with?

Now as to the macro parameter explanation, I'd love to say I understood it but I'm afraid it didn't quite penetrate my thick skull :roll: Maybe if you had stuck with 'first' and 'last' and Bill Gates I could have related to it better :lol: 

I guess 'foo' and 'bar' relate to my 'first' and 'last' and myfamily relates to Bill? But, you didn't mention anything about the 2nd parameter so I guess your example is for a one-parameter situation like this maybe?

```
on init
  name(myfamily)
  message(myfamily.bar)
end on

macro name(foo)
  declare const foo.bar := 6
end macro
```
Now if I consider your statements:


> So if "myfamily" is passed as parameter foo to the macro, then foo.bar would be replaced by myfamily.bar.
> 
> However, a hyptothetical reference to the variable foobar wouldn't match and would remain unchanged. This is where you can go further with the macro parameter names using #. If there is a #foo# parameter whose value is myfamily, then #foo#bar would be changed to myfamilybar - unlike what happens in the previous case.


It seems like in the 2nd set of statements you are describing something like this:

```
on init
  name(myfamily)
  message(myfamilybar)
end on

macro name(#foo#)
  declare const #foo#bar := 6
end macro
```

According to what you have said (and interpreted by me), as illustrated with the two code fragments above, both of these should compile OK. However, the first one doesn't 'work' unless I also use #foo#.

Now, I guess what needs to be clarified is, if foo.bar is actually replaced by myfamily.bar, why doesn't my first example work? Perhaps I don't understand what you mean by a hypothetical reference to foobar (unless you actually meant hyptothetical :lol: ).

If I didn't know that the first example doesn't work, I would have thought what you were saying was that the # thing allows substitution 'within' or for a portion of a variable name whereas otherwise it would only work if the parameter completely matches the name (or at least the part before or after a '.' but, if that *is* what you are saying, then the first example should work as is shouldn't it? 

Boy am I ever confused, huh? :? 

Rejoice,

Bob

Could it be that the part about scanning up to the first '.' is not actually working as intended?


----------



## kotori (Mar 14, 2011)

Big Bob @ Tue Mar 15 said:


> Could it be that the part about scanning up to the first '.' is not actually working as intended?


Yes, you seem to be right. Apparently there is an error related to how macros (but not functions I think) scan up to the first dot. I will try to look into this as soon as I get time. In the meanwhile you can use the # system as a workaround.

Cheers,
Nils


----------



## Big Bob (Mar 15, 2011)

Thanks Nils for restoring my sanity. :roll: No hurry about correcting this, I'm quite happy with using the # workaround. I just wanted to be sure I understood how things were supposed to work. 8) 

Rejoice,

Bob


----------



## kotori (Mar 15, 2011)

Hi Bob,

I think you may need to check the spelling


----------



## Big Bob (Mar 15, 2011)

Oh how embarassing :oops: I must have re-read the path names 10 times because I thought for sure that it must be a spelling problem. Too bad I didn't check the spelling of the command itself! So, it isn't conpiled then huh :lol:


----------



## kotori (Mar 15, 2011)

Big Bob @ Tue Mar 15 said:


> Oh how embarassing :oops: I must have re-read the path names 10 times because I thought for sure that it must be a spelling problem. Too bad I didn't check the spelling of the command itself! So, it isn't conpiled then huh :lol:


No problem. I wonder however if KScript Editor need not be made more robust and user-friendly in order for mistakes like these to be avoided. Your case clearly shows what problems can be caused by just mistyping a single letter. Maybe something like this would be the solution:





No offense meant. Just couldn't resist since the image seemed to fit this case so well


----------



## Big Bob (Mar 15, 2011)

Oh Nils, that's just hilarious :lol: How do you come up with these things? :roll: Maybe it was my Bill Gates macro example that got your thoughts in the direction of the hootchy-kootchy paper clip? :lol: 

But, lest you're feeling a bit smug about now, let me remind you of your recent:


> However, a hyptothetical reference to the variable foobar wouldn't match and would remain unchanged.


I better be careful here though because maybe there really is such a thing as a hyptothetical reference. In fact, it may be the only reasonable way to reference a variable named foobar (at least without getting a dancing paper clip)  

I know you are probably sound asleep by now, but, maybe this will start your day right :mrgreen: 

Rejoice,

Bob


----------



## kotori (Mar 15, 2011)

:lol: 
I'm having humble pie for breakfast.


----------



## Big Bob (Mar 22, 2011)

Since I have finally got back up to speed, I thought I would re-read this thread because maybe now I could offer some input about the upcoming compiler enhancements.



> multidimensional array declaration, eg:
> declare %array[10][10] {becomes %array[10 * 10]}
> %array[7][1] := 5 {becomes %array[(7*10)+(1)] := 5}



Couldn't you just use the more or less standard double subscript notation: %array[7,1] instead of %array[7][1]? 



> I'm making some progress on a new (yet unreleased) version of my script compiler. However, in its current state it does not support passing function names as parameters to functions (the same thing works for macro parameters however). I thought I'd ask those of you who use KScript Editor to what degree you rely on being able to do that. My guess is that many people probably have not even considered that this was a possibility in the past.



I have in the past, passed function names this way but I think that was before the introduction of macros. If macros can still do this, I think I could get by with that. I am currently using macros this way and I would hate to lose that.

BTW I just noticed recently that indented function definitions do not get displayed in the 'directory pane' or whatever that thing on the left is called. Sometimes its desirable to indent subordinate function definitions to show hierarchy so it would be nice if their names still showed in the directory pane.

Rejoice,

Bob


----------



## polypx (Mar 22, 2011)

You're blowing my mind. This is what it felt like trying to read that book on string theory: "imagine an ant walking on a wire".

But somehow I get it... arrays of arrays. Powerful stuff.


----------

