(Lurker)

2004-05-26 09:01 PM

Organization of Kixtart documentation

I'm working a Visual Studio type editor for Kixtart. It has indexed help, intelli-prompts (like intelli-sense) support for enumerated types, auto indentation, code completion and syntax highlighting. I'm getting ready to import the help information and I noticed that the ScriptLogic language reference is divided into essentially commands, functions, and macros. Unfortunately, I need a more traditional categorization of these elements since there are specific rules applied to each element type.

Items such as IF, While, Sub, Function, GoSub, and For are commonly referred to as statements since they control the flow of code.

+,*,-,/,=,<,> are traditionally called operators as they are used in equations.

Del, Play, MD are referred to as commands even though they appear to be functions. Can anyone shed some light on the reasoning of the categorization in the Kixtart help file?

While I can hide the traditional categorization of these language elements and present the KixHelp categories, IMHO not only does the distinction help clarify the language but the inconsistency, when for example somebody sets their highlighting preferences, is confusing.

Feedback is most appreicated.

(KiX Supporter)

2004-05-26 09:27 PM

Re: Organization of Kixtart documentation

see kixscripts.com

(Lurker)

2004-05-26 09:55 PM

Re: Organization of Kixtart documentation

Their online reference is organized the same as the CHM file.

(MM club member)

2004-05-26 10:28 PM

Re: Organization of Kixtart documentation

I'm not sure how Ruud comes up the distinction of what should be a function and what should be a command. From a reference standpoint all the commands (e.g. Del, Play, MD) have their parameters wrapped in quotes(e.g. "parameter"), whereas function parameters are enclosed in parens.

(KiX Master)

2004-05-27 06:32 AM

Re: Organization of Kixtart documentation

Commands have no return values (except maybe through a macro).

Richard H. Administrator

Administrator

(KiX Supporter)

2004-05-27 10:34 AM

Re: Organization of Kixtart documentation

Quote:

Commands have no return values (except maybe through a macro).

Yup, that's how I've always viewed the differences.

Almost all commands (other than language intrinsics like flow control statements) should IMO be functions.

Ok, so maybe you are not interested if something like Sleep fails (though maybe you should be) but you almost certainly are interested if MD, CD, DEL and so-on fail. @ERROR is set so that you can determine success, but for language consistency you might reasonably expect to be able to do "If Not MD('c:\temp\mynewdir')"

KiXtart is full of odd language anomolies, introduced as it has been developed. "GetS" is a command, but "ReadLine" is a function. "Del" and "Move" are commands, but "SetFileAttr" is a function.

I'd guess that the strange syntaxes are for early commands which emulate DOS batch commands. They have persisted because of backwards compatibility.

I'm sure if Ruud started KiXtart again, we would have "$Input=GetS()" rather than "GetS $Input". It would certainly make the parser simpler

Administrator

(KiX Master Guru)

2004-05-27 10:57 AM

Re: Organization of Kixtart documentation

hmmm...
don't think your reasoning is so well eaten.

doh, I'd understand gets as function if you could pass a param to it.
say gets($filepipe)

but, the thing between command/function separation most likely is:
if it has only one argument and it is not for quering data, there is no reason to make function.
with more params and the need to return something, makes a reasonable function.

well, as I type this, I see gets indeed might be function

also, memorising my TCL codes, there basically is no such thing as function or command.
well, differentiation between them.
all the stuff works the same, just as kixtart commands (with lots more optional params though)

Richard H. Administrator

Administrator

(KiX Supporter)

2004-05-27 01:09 PM

Re: Organization of Kixtart documentation

Why would "Del" be a command, but "SetFileAttr" be a function?
They both have parameters, and neither has a return value other than the success status.

To turn it the other way around, why is "GetS" a command, and "FreeFileHandle" a function? Neither has a parameter, so for consistancy either "GetS" should be a function, or "FreeFileHandle" should be a command.

AT() is another odd-ball.

I'm just responding to schneiders request for clarification.

The point is KiXtart is inconsistant and a little strange because of the way it has developed over time, and the need to preserve backwards compatibility.

We all look back at our early code and think "Well, I could have done that better."
One of the Unix authors was asked if there was anything he would change if he could start again, and he replied (paraphrased 'cos I can't find the quote) "Yeah, I'd put the 'n' in 'umount'"

Going forward, perhaps these commands should also be available as functions with the command syntax being supported but deprecated.

It's not really a big issue, but it would tidy things up.

(Lurker)

2004-05-27 08:52 PM

Re: Organization of Kixtart documentation

I certainly don't mean to criticize. My primary concern is the lack of distinction in flow control statements. Having a fuzzy line between commands and functions is fine if your willing to say "A command is like a function but different. However, FUNCTION, SUB, IF and FOR are certainly not functions.

Anyway, here is the problem....

Unless I set highlighting, indentation, code-completion, and error checking rules on every keyword in the language (which is not practical or maintainable at all), I have to make the distinction regarding statements, operators and Functions/Commands. There is no issue with having both commands and functions but those elements that are traditionally statements and operators need to be distinct from commands because they are distinct in both editing rules and in pre-processing of the code.

The editor’s language processing and indexed help system is built from the same keyword database to facilitate maintenance and extensibility.

I can take two approaches in the Help System:

1.) Have the help reflect the Kixtart classification of “Commands” covering Statements, Operators, and Function Like things, which in my opinion this approach doesn’t solve the inherent issue with clumping them all in one group and introduces confusion when you go into the “Highlighting Preferences” menu and see different classifications than help.

OR

2.) Have the help system reflect the distinction in the categories, which overcomes the above cons but again introduces confusion by deviating from the community standard.

I really would like to hear your thoughts. Also, if you are willing please note if you’ve coded in another language.

schneider

Administrator

(KiX Master Guru)

2004-05-27 09:28 PM

Re: Organization of Kixtart documentation

well, I think the community standard is the one in the bible (kixtart.doc)

Richard H. Administrator

Administrator

(KiX Supporter)

2004-05-28 10:15 AM

Re: Organization of Kixtart documentation

I guess that originally KiXtart had only commands, with support for functions coming later. This would have meant that early documentation dealt with operators, variables and everything else. Everything else was lumped under the title "commands".

The documentation is dodgy in places. I don't think that there are any real errors left, but it does need a bit of an overhaul to update examples, fix ommissions and add clarification to some of the entries.

Things like "dim", "do until", "for next", "if endif" are clearly not commands - they are language control structures.

Things like "display", "cls" and so-on are clearly commands.

Things like ":" (label) are normally also differentiated for syntax highlighting.

Other language control statements like "BREAK" and "DEBUG" are a little harder to categorise. They are definately not control structures, but they don't really fit into the command category either.

For syntax highlighting (and indenting etc) purposes it is not appropriate for language control constructs to be categorised with the rest of the command set.

Fortunately, the distinctions are obvious. You can therefore run through the commands section of the manual and decide which category the commands best fit into. A number of us support syntax files for other editors, and that's what we did

I "maintain" the VIM syntax file, which is a little out of date now. You are welcome to download the editor, or I can mail it to you if you'd like to just look at the syntax file itself.

If you'd like to look at the syntax files for other languages, either search for them on the board or ask.

I recommend that you start a new thread in the General forum, as this thread is not really appropriate for the suggestions forum.

Quote:

Also, if you are willing please note if you’ve coded in another language

Loads. Other than KiXtart highlights are: DataBasic, A*L*L (Pick), Informix 4GL, C, Forth, various JCLs, AWK, Ksh, Bash, HTML, PHP, PERL (briefly and never again I hope), Java, JScript, Assembler, Machine Code (definately not my favorite!), VB, VBA, VBScript and a load more.

Or did you mean "spoken" language?

Administrator

(KiX Supporter)

2004-05-28 02:05 PM

Re: Organization of Kixtart documentation

Quote:

...PERL (briefly and never again I hope), ...

lol, Amen to that, my brother.

(MM club member)

2004-06-03 08:21 PM

Re: Organization of Kixtart documentation

Will this editor be free?

Administrator

(KiX Master Guru)

2004-06-05 05:18 AM

Re: Organization of Kixtart documentation

heh. why you ask?

anyway, if it's not free, he should have something in there others do not to make it attractive.

(MM club member)

2004-06-09 12:01 AM

Re: Organization of Kixtart documentation

Well it was just out of plain curiosity, considering how the first post was formed