Page 1 of 1 1
Topic Options
#120224 - 2004-05-26 09:01 PM Organization of Kixtart documentation
schneider Offline
Lurker

Registered: 2004-05-26
Posts: 3
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.


Edited by schneider (2004-05-26 09:03 PM)

Top
#120225 - 2004-05-26 09:27 PM Re: Organization of Kixtart documentation
Radimus Moderator Offline
Moderator
*****

Registered: 2000-01-06
Posts: 5187
Loc: Tampa, FL
see kixscripts.com
_________________________
How to ask questions the smart way <-----------> Before you ask

Top
#120226 - 2004-05-26 09:55 PM Re: Organization of Kixtart documentation
schneider Offline
Lurker

Registered: 2004-05-26
Posts: 3
Their online reference is organized the same as the CHM file.
Top
#120227 - 2004-05-26 10:28 PM Re: Organization of Kixtart documentation
Chris S. Offline
MM club member
*****

Registered: 2002-03-18
Posts: 2368
Loc: Earth
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.
Top
#120228 - 2004-05-27 06:32 AM Re: Organization of Kixtart documentation
Sealeopard Offline
KiX Master
*****

Registered: 2001-04-25
Posts: 11162
Loc: Boston, MA, USA
Commands have no return values (except maybe through a macro).
_________________________
There are two types of vessels, submarines and targets.

Top
#120229 - 2004-05-27 10:34 AM Re: Organization of Kixtart documentation
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4945
Loc: Leatherhead, Surrey, UK
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

Top
#120230 - 2004-05-27 10:57 AM Re: Organization of Kixtart documentation
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22343
Loc: OK
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)
_________________________
!

download KiXnet

Top
#120231 - 2004-05-27 01:09 PM Re: Organization of Kixtart documentation
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4945
Loc: Leatherhead, Surrey, UK
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.

Top
#120232 - 2004-05-27 08:52 PM Re: Organization of Kixtart documentation
schneider Offline
Lurker

Registered: 2004-05-26
Posts: 3
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


Edited by schneider (2004-05-27 08:57 PM)

Top
#120233 - 2004-05-27 09:28 PM Re: Organization of Kixtart documentation
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22343
Loc: OK
well, I think the community standard is the one in the bible (kixtart.doc)



_________________________
!

download KiXnet

Top
#120234 - 2004-05-28 10:15 AM Re: Organization of Kixtart documentation
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4945
Loc: Leatherhead, Surrey, UK
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?

Top
#120235 - 2004-05-28 02:05 PM Re: Organization of Kixtart documentation
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
Quote:


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





lol, Amen to that, my brother.

Top
#120236 - 2004-06-03 08:21 PM Re: Organization of Kixtart documentation
masken Offline
MM club member
*****

Registered: 2000-11-27
Posts: 1222
Loc: Gothenburg, Sweden
Will this editor be free?
_________________________
The tart is out there

Top
#120237 - 2004-06-05 05:18 AM Re: Organization of Kixtart documentation
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22343
Loc: OK
heh. why you ask?

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

download KiXnet

Top
#120238 - 2004-06-09 12:01 AM Re: Organization of Kixtart documentation
masken Offline
MM club member
*****

Registered: 2000-11-27
Posts: 1222
Loc: Gothenburg, Sweden
Well it was just out of plain curiosity, considering how the first post was formed
_________________________
The tart is out there

Top
Page 1 of 1 1


Moderator:  Lonkero, ShaneEP, Jochen, Radimus, Glenn Barnas, Allen, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 162 anonymous users online.
Newest Members
Jodey, Hiker, GTRoberts, KatieQuinn, Brennnnn
17684 Registered Users

Generated in 0.04 seconds in which 0.012 seconds were spent on a total of 12 queries. Zlib compression enabled.

Search the board with:
superb Board Search
or try with google:
Google
Web kixtart.org