RUSSIAN(Русский)
ENGLISH


This function requires cookies.
If the browser does not accept cookies,
the light theme is used always.

    Introduction
 

Here plans on perspectives of AL-IV (ALFOUR) programming language development are represented.

 
 

My current plans

(in form of "cards")

 

 

My old plans from 2016

to 2020 (mainly implemented):

 

 

What to do

What is doing

What is already done

What was cancelled
   
Visual programming - finished and can be used. Though special modules can be necessary to connect to MS SQL or mySQL or smth else but this is not too hard to add them on demand.
 
   
A way to program for Linux is there - at least via the Free Pascal + the Lazarus. It is also possible also to compile the compiler itself (AL-IV -> Pascal) working under Linux, and then develop under Linux w/o Windows at all. (If something was broken in current version it is not too hard to repair it in a short time).
   

Multithreading: it is mainly ready but result is very doubting. There are very big time expenses there for creating / working / supporting threads themselves, in result - only slowing down total time of working or very small speeding up in rare cases. The multi-threading has a sense in case of dividing the work onto sub-tasks of very different kinds (such as data exchange with HDD, with DB, calculations, graphics, sounds producing).
 
IDE + Form Designer + Menu designer + Report designer 
  
  RTTI: class {RTTI} + embedded support for RTTI  
   

The interpreter - ready (almost) version for C#. Speed is disgusting but for C# it is enough. It is very good to run light weight applications without compiling.
  
   
Android platform support. Java for Android used + Android Studio + adb drivers should be installed, building via command line works.

Due to a large amount of hard working on the subject, it has its own planning desk.

 

Mac / iPhone.

 What concerning Mac / iPhone: this dying platform seems not necessary to support.
The Profiler can be obtained almost for free, still function call counters are always in the code (except the option /final on).
      

 

    What is done already

 

Form designer
 

Implemented. Even with a menu editor. There is not enough only a report designer. And components/classes fro printing.

 

Parallel programming
 

What to do

What is doing

What is already done

What was cancelled
   
An object is isolated totally in a thread where it is only accessed at a time. An isolation done for an object and (if this is specified) for all the objects hard linked from the isolated objects tree (recursively), and for all the objects hard referenced only from the object isolating with a hard link (also recursively).

When a thread is ended (or an isolated object is passed as an intermediate result without/before ending the thread), all such objects are "returned" together with its "parents" and again become referencing in the thread which was initiated the secondary thread.

To pass objects dynamically, the method Take is used:
Take({Object} A|rray_of_objects[], BOOL Together_with_all_hard_linked_objects)
Sent objects disappear from the sending thread address space: all the links on it are replaced onto links to NONE objects.

To return objects back to the sending thread, the slave object uses yield operation, or just replaces all the links onto the object returning onto NONE, and when the secondary thread no more referencing the object received, it automatically is returned home.

To provide a possibility to handle parts of usual arrays in threads, the special class {Slice} is created which allows to exclude a part of an array (without moving it in the memory physically if this is possible), after that it can be passed to a thread the way described above as an object.
Special syntax constructions. Simple way finally implemented, without adding any special language constructions:

a special object of base class {Thread} generating (on Run) another "controlling" thread instance, leaving at the side of launching thread and allowing to send objects and do something other control operations from the parent thread side.
Read only accessing from a sending thread to {Slice} fragments of arrays passed to nested threads. It is required to provide physical protection of data from writing. If implemented this allow preventing data copying before passign sub-arrays to nested threads while sorting data (using quick sort). This may increase speed and finally achieve performance features from parallelism.
      
 

 

Android platform support
 

Java + Android Studio is used, and this way is working.

 
 

What to do

What is doing

What is already done

What was cancelled
   
The compiler ALIV -> Java. The previous version was oriented on the oririnal simple framework awt, not to the Android. But the Java language iself is the same, only libraries are different.
Supporting awt visual library. It seems that it is not sense to orient on any desktop framework of the Java. There are no there sufficientl ready to use, all are not finished and bugged. It is enough to find how is the installer of the Java (from Oracle) is looking like. Nobody see its buttons going to gone?
   
Developing visual applications for Android (for now w/o OpenGL). The goal is to allow running a minimal application containing the single empty form on the device with the Android 5 or above.
  
   
Launching an application containing several forms and basic components (such as label, button). Handling touch events on all the items. Drawing on a bitmap and saving PNG file. Creating a log file (redirecting console output to the log file). Correct layout of components on a form.

Switching between forms using system menu (modified). Programmable Exit from there.

Modal dialogs (single button OK or buttons YES/NO). Handling the system button Back ([<]): ending modal dialog / going to the background.

Text input in the {Paint_lines} component, with caret showing the input position.
  
   
Basic GUI applications. All the tests from Test_visual_projects and some from Demo folder are compilable and working.
  
Dialogs to select files/folders to open/save file
 there.		   Drawing on the canvas (consider rotations/other transformations, correct shapes drawing, filling drawing text, bitmaps etc.)  
   
Handling events. Save/restore the application state on a signal from the system about ending the app.
  
   
OpenGL for Android.
  
The IDE AL4 under the Android should work, at least as the editor with syntax highlighting and other language-oriented features.
      
   
Console applications under Android (in the emulation the console window: for console apps, the stub application Console_app is embedding).
  
The interpreter under the Android. It should allow developing applications for Android under the Android. At least while testing/debugging.
      
 

 

 

RTTI
 

To pass data sets from objects to sets of visual items ({Edit}, {Checkbox}, {Combo}, {Memo}, ...) and backwards and do not write a lot of primitive assignments in the code like
Edit_something.Set_text(
    obj.Something)
Checkbox_number_1.Set_checked(
    obj.Some_flag_set)
Combo_number_2.Select(
    Combo_number_2.Find(
        obj.Item_X))
... etc.

Instead to make it possible to call a function like Read_values_from_obj, which could list all the fields of an object passed and find among them fields corresponding to visual components on a form, and then assign them values of fields found.

As well as in the backwards direction, too, plus colring to RED controls which can not be put into objects (e.g.)
 

To perform such task it is possible to use the class {RTTI}. In such case enough information about objects is stored in the code compiled and some additional functions are generated which allow to enumerate fields and also to get information about is types, names, sizes, and also to read and write its values (including array fields).

Also the {RTTI} alloww to provide a mechanism of data isolation  of objects between threads (using methods Take/Yield of the class {Thread}).

 

 

The interpreter
 

Can be implemented (though with some hardness / restrictions). And even with a hope to obtain good enough (for interpreters) execution speed.
 
 

What to do

What is doing

What is already done

What was cancelled
   
The interpreter implementation on C#. From the one side, it is easy to debug code on C#. But from the other side, C# does not allow to flow down sufficiently in code level to speed up the interpreting enough. In result, it is running about 200 times slower then the direct machine code compiled. Though this is not important for debugging or for implementing visual interfaces while it is not necessary to handle millions of bytes a second.
 
The interpreter on Delphi. Theoretically can allow make smaller the difference between the interpreter and machine code in speed (about ten times). But useful only on two platforms: Windows and Linux.
      
The interpreter on Java - for the Android platform. Speed problems the same as in C# but the feature is that this is (it seems) a single way to allow developing on the Android since there are no possibility to compile code directly on the Android device.
      
 

 

 

 

IDE AL-IV
 

It is necessary to reject from attempts to use the compiler as a part of the IDE to analyze the editing code. And switch to a simplified analyzer embedded into the IDE editor. In such case we can add some extended handling of erroneous and suspicious cases which occur just because the text is just typing and is not finished properly.

Priority: IMPORTANT.

What to do

What is doing

What is already done

What was cancelled
   
The text editor with the syntax highlighting for the AL-IV language. It has the capability to navigate to functions and fields. There are hints on function parameters in it. The form designer and menu designer are there too.
The preliminary code compilation to provide hints on functions, variables, classes etc. was cancelled because this is much slower then direct text analysis.
   
It is possible to run the compiler directly from the IDE, then showing a list of errors/warnings and with the capability to navigate in them in code just clicking it. And this navigation stays correct while the code is editing. The only disadvantage is that the editor is not available until the end of compiling/running the application.
 
Parallel working of the IDE and the compiler/application launched from the IDE.
      
Embedded step by step debugger (using the interpreter).
      
Integrating with the profiler (goal is to show visually most often running statements).
      
Hints on library functions and project functions even from not loaded classes (hidden shadow loading those classes in read only mode).
      
Quick tips on variables (full name of variable/field, constant value), functions, data types when mouse is hovering an identifier in a code (without mouse click on it).
      
 

 

Debugger embedded into IDE
 

This feature is not required more. For this time, we have already something better: the incremental compiling with dynamic re-loading re-compiled classes without restarting an application debugging.
 

The only disadvantage rest there: for this time, incremental compiling with dynamic code re-loading is available only for Delphi/VCL. Though there is no problem to debug first under such platform, then build an application for a desired platform.

 

 

 

Content

     Introduction

My current plans

My old plans from 2016

    What is done already

Content

 

 

 


 Home