WHS: Programming projects: wsh

wsh was developed based on an assembler for which I developed almost a complete programming language, so why not make that a new separate language?

A motivation to do this was especially to make a replacement for current shells: bourne/bash/korn/c-shells are all truly awful when used as a programming language. They suck in speed, they report errors badly or even just continue doing something stupidly despite an error, and they are extremely limited.

Programs I write for shells never work properly the first time, it's all very unintuitive and I often get weirdnesses (one method working fine in one version of the shell, not in another). Shell programming is also notoriously difficult to do portably over various (unix-like) operating systems, so I want to use wsh as a shell, make replacement (see further on), programming language for utilities and prototyping etc.

The goals are: small, fast as possible, useful and intuitive, proper error checking, proper diagnostics.

Another major suckage in programming is 'make' which suffers from similar issues as shells, such as TABs or spaces being treated differently in some places, and it does things differently than sh, e.g. conditionals, so you need to know 2 different programming types. Also 'make' is quite ungainly in concept... Most of the functions you want in a 'make' program are already there in a shell type program and build rules can easily be specified in a proper programming language, so combining them seems logical to give a system language.

Btw., even worse than any of these are autoconf and automake, as so often with gnu stuff they just embrace and extend even if it's stupid. Most of what's in those programs should be placed in compiler files as I noted many many years ago somewhere else already (possibly in discussions about EIffel in the late 1990s, I'd need to look it up). In case of autoconf: instead of each program running a 'configure' script to determine compiler capabilities (which is slow), such a script should only be run once and stored as a compiler-capability file, and updated only if a newer or different compiler is used or if other tests need to be done.

Design goals

• Easy to understand, no cryptic syntax like ${a#DCS_} to denote removing the characters DSC_ from the string variable 'a'. This is unreadable and when you've not used sh for a few months or longer, then you think "What the hell does this do?" or when writing an sh program "How do I remove the beginning (or end) of a file name?"
• Proper error reporting, quite unlike sh which is one of the worst ever programs in how it often is simply not doing what I want/expect and the reason why this is so, is unclear because of no useful error messages and the way variables and strings are handled.
• Proper variables, not needed to declare them at the start but possible if desired. No value designations of incompatible variable types. Variable types: CHAR, INT32, INT64, FP32, FP64, STRING, LIST (of any number of any types of variables, so a list can contain any types and lists of lists can be part of it). Perhaps add vector/matrix, but they could be simply a list (vector) and list of lists (matrix)
• Proper calculation, all the useful functions including sin, cos, tan, factorial, power, but also bit functions
• No indentation to signify structures as in python, but end<startname>, or using brackets (at the moment I'm using end, so for/endfor, loop/endloop, if/endif etc.
• Small and fast
• Proper string slicing functions
• Easy to use file information functions (stat (2))
• Simple graphics functions to be able to do visualising, this need not cost much space and can be placed in a dynamic library (to be dlopen'd so as not to introduce runtime dependencies if they are not used)
• Interactive mode with:
  • Command history (with removing of duplicates) but also something more that I haven't seen elsewhere. Description to come once implemented...
  • Filename completion in a different way...
• Possibly other stuff that seems forgotten these days but which was popular in the 1980s, one of these is:
  Pretty printing output, but not just indenting. More on this to come, this is something I've done with my assembler already.

More to come soon.

Download

To come

Copyright

BSD 2 clause. Contact me if you have any questions.

Well, mostly valid :) And no Flash, no Java, for a fast website... This site is made using open source software, in particular FreeBSD.

Last modified: Tue Jan 28 03:56:53 CET 2014