OSDev.org

I haven't been able to find a scripting language that suits my needs for my hobby os. In the end, I figured it'd be best to roll my own. These are some of the goals I have in mind:

• Capable of treating lines of code as commands to execute programs or open resources (like in DOS and Bash)
• Suited for operating on streams like Perl
• Very easy to parse, with a small set of reserved keywords
• Supports parallelism and concurrency
• Supports capturing signals for exceptions and events

I haven't gotten anywhere yet, but the planning process has been very interesting because it's forced me to think outside the box for things like how functions work. Consider the following code:


The gist of it is that the 'do' keyword is used to encapsulate a set of instructions between curly brackets to form a macro instruction. This macro instruction will have closure with it's own local scope. It can also be labelled by placing a colon followed by an indentifier between the 'do' keyword and the curly brackets. The extra parameters after "BuildFile" are passed like $0, $1, $2, etc. to the 'do' block. Inside the block, they may be aliased with more canonical names.

Another idea I had is that all 'call' instructions should fork into separate threads if possible. An 'on' instruction would be used to capture signals, similar to a 'comefrom' instructions. A 'hang' instruction suspends execution indefinitely, only listening for signals. Think of it as the complete opposite of a 'call' instruction. Rather than "going [to a label] and coming [back to the return place]" it's "coming [back to itself] and going [to a signal handler]".


I've never seen any other programming language handle functions like this myself, but it's probably nothing new. Does anyone else know a language that does something similar which I can look at for ideas? Also, what is your opinion? Would you use it if you had the choice or throw holy water at it?

I think I must misunderstand your explanation because I can't see anything special about the way that your language handles functions (apart from the idea of handling function calls as threads - which seems inefficient and to have potential synchronization problems). You have some extra verbiage, like "call" and "do:", which other languages manage very well without; I can't see what they bring to the party.

As it stands I can see no reason to use this language over one of the many established scripting languages. Perhaps a fuller explanation of its advantages could convince me otherwise.

You do have a point about the inefficiency of it. What I'm wanting to do is have both synchronous and asynchronous calling methods. 'call' and 'hang' in particular are to be used for asynchronous execution; where 'call' starts a function in a new thread and hang perhaps creates a barrier of sorts for execution to finish.


The use of the 'do' keyword in the example is not a tradional usage of the 'do' keyword. It wraps and labels a macro instruction with it's own closure and scope. This can be very useful for metaprogramming and it greatly simplifies parsing.

The extra verbiage is necessary to differentiate commands like "gcc /o test test.c" from things like 'int main (void)'. The first word in each statement tells the parser how the command should be interpreted. eg. "if <condition> then do {}" is actually shorthand for:

Keep in mind, one of the major purposes for this language is to be used in place of bash or batch scripts.

I'm not sure that that fits very well with asynchronous programming. And I'm also not convinced that implementing features because they simplify parsing is a good motive. (Make life easier for the programmer - yes; for the parser - not convinced.)

I still don't really see anything to be gained from this (yet another) proposed language so I'll pass.

For inspiration, you might want to look up the Go language with how they use channels and the 'go' keyword.

That's actually one of the things I've been looking at with regards to concurrency. It currently takes inspiration from Bash, Batch, Lisp, Go, and VB. Lisp in particular is where I got the idea for 'do'. That is to say that it's inspired by S-expressions. Each script can be viewed as a big 'do' instruction. There aren't any functions per-se, only macro-instructions. Macro's also don't have names but can contain labels. Like in Batch-scripting, you can use 'call' to branch to a label or separate script. One idea I had in mind with allowing macro labels is that you can perform multi-level breaks and continues for loops like in Java. VB is where I got the idea for 'on' signal handling. I wanted a quick and dirty way of polling user input like keypresses, handling exceptions, and receiving events (for use with toolkits). The overall syntax is inspired by Bash.

So, 2 more ideas:

*) I want to be able to expand code in a string like bash (eg. `pwd`) but rather than using backticks, I want to use uneven quotes like `pwd'. I got the idea from some macro language whose name escapes me, but it basically has the advantage of being able to do multiple expansions without having to use escapes like:

*) While mainly intended for use as a shell, I want to be able to do complex things things like stream manipulation, set manipulation, code manipulation, database indexing, signal handling, and ui creation as easily as possible to make it suitable for prototyping. Rather than using functions (or in my case, macros) they should all be integrated into the language itself.

It looks like Tcl/Tk.

That's because it's partially inspired by it

The power of Tcl + the flexibility of Lisp + the responsiveness of VB + the concurrency of Go + the hackability of Perl + the syntax of Bash is the sort of mental picture I've been building off of.

So, I've been getting a bit worn out working with languages like C and others with object-oriented paradigms. I went out googling for languages that were more human readable. Performance and accuracy were not factors, I just wanted something that would allow me to lazily slap things together quickly and thoughtlessly whilst I grunt and scratch my @$$. I have some prior experience in BASIC, which I haven't touched in forever, but it didn't feel lazy enough. Too much sophistimication.

After poking around looking at examples for languages like FORTRAN, Pascal, and Ruby; I happened to stumble upon this one example of Haskell where I noticed it used 'do' very similary to this scripting language I was working one. For some reason, even though I don't understand many of the examples, something just feels...right...about it. Idk, I can't put my finger on it, but when I happened to come across the following 2 examples my wallet instantly emptied it's contents at my monitor:
This is pure genius! I never would have thought of implementing unions in this way, and it just feels so elegant... This has given me a lot of ideas, and Haskell is definitely the next language I'm going to learn.

Here's an idea I just came up with that I don't think has been done before; multi-conditional switch/case statements.



the basic idea here is that rather than how a traitional switch/case statement works, the 'when' keyword is a conditional that specifies a certain value is to be the left operand of the following statement. eg.

would be valid. The 'is' keyword then creates a new scope like 'do' which applies that case to all the instructions inside of it. The 'or' keyword allows you to fall through by merging 2 statements like 'when i is <= 10 or >= 10'. Aside from being more powerful, it's just easier to read.


EDIT:
An expansion on this idea, the use of 'is' can apply to comparison of objects and a 'can' keyword can apply to implementation of methods. eg.

Basically, you can have a direct way of checking late-bound methods and conditionally executing code based on the functions that are implemented.

RPG has had this for decades (centuries??). http://as400bks.rochester.ibm.com/iseri ... 925084.pdf.

See the SELECT statement. PDF page 727.

Or, to take an example which is probably more familiar to many people, the Visual Basic "Select" statement. I'm sure these aren't the only languages where such constructs are available.

I don't dare say anything about Basic for fear of getting my butt kicked by Combuster

Considering you said that, maybe I ought to kick you now since I kick people with an disproportionate religious fear of basic.

Point is, every language has strong and weak points and the moment you refuse to accept that the only thing you can do ends up violating forum rule 7.