-
Programming is too complex...
08/05/2018 at 14:12 • 0 commentsIn'The Problem With Programming and How To Fix It' and other posts, slashdot nails that the software world has already reached critical mass and is exploding.
Wirth tried to rationalise algorithmics but Pascal is rarely used anymore. Ada has grown too much and the rest can be called "esoteric"...
-
Standard types
04/02/2018 at 04:25 • 0 commentsBCFJ's fundamental type is equivalent to BASIC's number, or C's "int". It's enough to get a few things done but won't go far...
Scalar types :
Defining the size explicitly is important, otherwise many problems appear.
Integer numbers are either signed or unsigned so the following types should be supported (if the processor can handle it) :
S8, S16, S32, S64 : Signed integer of 8/16/32/64 bits
U8, U16, U32, U64 : Unsigned integer of 8/16/32/64 bits
F16, F32, F64 : Floating point of 16/32/64 bits(I didn't add support for logarithmic, unlike in the early F-CPU, which was a dead-end...)
Characters... Are another thing. ASCII is only a relic now and UTF8 is the norm, which can have a crazy dynamic range. The norm limits the size to 21 bits (assembled from 4 bytes) so there is no actual "character" type as in C because the representation can vary wildly. However, intermediary types are possible for various representations (UNICODE point or byte serialised).
Strings too can have multiple representations (point or byte) and can't be handled directly in the core language. Yet this is very important and useful so a careful and simple design is required early on. Without proper string handling, no parser is possible... Usually, strings are very easy to process in plain ASCII but I don't want to make an ASCII mode at first because UTF8 will never get implemented later. Is the development of UTF-8 library holding everything back ?
-
Typing
04/02/2018 at 03:26 • 15 commentsWhat's best ? Pascal's strong typing or JS' weak typing ?
Both have excellent arguments but also significant drawbacks.
It's hard to reconcile both.
Since BCFJ starts as an interpreted language, typing can be weak and in fact, the first type is "a number" (think "int" in C).
Later, when objects ("blobs") are introduced (à la JS) a stronger typing mechanism can be introduced. The trick is to have/check the "type" attribute, which points to a collection of handlers that then resolve the types, convert or compute values...
So BCFJ does not enforce a typing mechanism or precise resolution behaviours from the beginning (this removes a LOT of red tape from the language). Later, conventions can be added to prevent inconsistencies or adopt the preferred behaviours.
So BCFJ starts "naked", like in FORTH, with an "integer" type, which is then completed... See the next logs.
Oh my... -
Units
03/31/2018 at 04:52 • 0 commentsHave you ever used Turbo Pascal ? or Ada ? Or VHDL ?
In TP, you can make a program, but also share code with what's called "units". They are named "libraries" in VHDL.
In BCFJ, everything is a "unit".
A "unit" is code, linked to other units by a collection of entry points.
- One entry point is meant for initialisation (it's called "init", and might be the first ever entry point)
- Others can provide functions to accepted processes.
When "init" is void/empty/absent, the unit is comparable to a shared library/dll.
The "Init" can also be equivalent to the "main" in C/POSIX. Other entry points are not absolutely required but they can provide asynchronous signal handling for the unit.
Unlike POSIX shared libraries, a direct call is not possible, units have separate and protected address spaces. The calling process must perform an Inter Process Call and send the information through the registers and shared memory spaces.
Some units can be IPCalled and access the calling process' address space BUT can't use any other space at the same time : they provide shared routines, that's all. Data leaks shouldn't be possible unless explicitly requested...
Remember : units do not have to trust each other. The caller and the callee should not assume benevolence, security and/or safety. A unit could be replaced by a different version between IPCs, either for maintainance or because something went wrong... So don't let any unit's code access your private data.
This is where "capabilities" and process properties become essential. In order to let other units call you or accept your call, you need reliable information about their rights. For example you can't let anybody call your "init" entry point (only a given process can do this and its process ID might change, but not its access rights)
-
Note for later
03/16/2018 at 13:56 • 0 commentsNobody reads the early design notes. But dear future self, I warn you about the dangers of this.
https://thedailywtf.com/articles/A_Case_of_the_MUMPS
https://thedailywtf.com/articles/MUMPS-Madness
...
On the sunnier side, https://blog.codinghorror.com/a-scripter-at-heart/
-
The need for a preprocessor
03/10/2018 at 11:05 • 0 commentsCompiles languages often have a preprocessor (I'm looking at you, Ada/VHDL...). Scripting languages don't.
Since this is based on a scripting engine (with an interpreter that manages files inclusions etc.) there is no need for preprocessing or substitution. The dynamic environment does the preprocessor's work as well as "elaboration" (like in Ada/VHDL). The "source code" contains not only the instructions to execute but also how to execute them...
-
A bit of historical perspective on early language design
03/09/2018 at 05:31 • 0 commentshttps://www.bell-labs.com/usr/dmr/www/chist.html has been added to the Files section.