Read more here.
Amiga E, or very often simply E, is a programming language created by Wouter van Oortmerssen on the Amiga.
Amiga E is a combination of many features from a number of languages, but follows the original C_Programming and C++, most closely in terms of basic concepts like in the sense that it is fast and weakly typed, and had a rich set of features from procedural, object oriented and functional programming languages.
Amiga E's main benefits are fast compilation (allowing it to be used in place of a scripting language), very readable source code, flexible type system, powerful module system, exception handling (not C++ variant) and object oriented programming.
Contact the AmigaE IRC channel irc.freenode.net at #amigaE
For further information and questions, Portable E has its own forum here. PortablE is an AmigaE compiler, written from scratch in E, and able to compile itself. There is a mailing list for E where you might get some answers.
Read more here.
This is how PortablE works. You write your Amiga E code, use PortablE to translate it into a .cpp file and then use any C++ compiler to compile the file into an executable. I have been using g++ inside AROS. If you want to go to Amiga Classic, you can use PortablE to translate to Amiga E and then move it to Classic where you can use an Amiga E compiler like CreativE.
If PortablE is not already set up for use, you need to set a Stack of at least 100000 to run PortablE. You can set this up by typing in the AROS shell.
You need to do an assign for PEmodules.
Assign PEmodules: VolumeName:PEmodules
You can put Assign commands like this in your user-startup file in AROS so you don’t have to do it everytime. User-startup is in System:S (S drawer).
You also need some Assigns placed in there for g++. The exact Assigns you need can be found in the INSTALL file located in System:Development
So here are the commands I entered on the command line once I had things setup to test a simple program.
PortablE test.e (This gave me a file named test.cpp)
g++ test.cpp -o test (This gave me a file named test to run as an executable)
So then I just typed in the name of my executable at the shell and it ran and printed “Hello, World!”.
Read more here.
A "hello world" program in Amiga E calling another procedure inside
PROC main() DEF z WriteF('Hello, World!\n') z:=1 Another() ENDPROC PROC another DEF y y:=2 ENDPROC
IF x>0 x:=x+1 WriteF('Increment: x is now \d\n', x) ELSEIF x<0 x:=x-1 WriteF('Decrement: x is now \d\n', x) ELSE WriteF('Zero: x is 0\n') ENDIF
SELECT x CASE 0 WriteF('x is zero\n') CASE 10 WriteF('x is ten\n') CASE -2 WriteF('x is -2\n') DEFAULT WriteF('x is not zero, ten or -2\n') ENDSELECT
PROC main() DEF x x:=1 WHILE x<=100 WriteF('\d ', x) x:=x+1 ENDWHILE WriteF('\n') ENDPROC
PROC main() DEF x x:=1 REPEAT WriteF('\d ', x) x:=x+1 UNTIL x>100 WriteF('\n') ENDPROC
PROC main() DEF x,y x:=1 y:=2 WHILE (x<10) AND (y<10) WriteF('x is \d and y is \d\n', x, y) x:=x+2 y:=y+2 ENDWHILE ENDPROC
- The procedure definition.
- The declaration of the procedure main, with no parameters.
- The declaration of local variables x and y
- Initialization of x and y using assignment statements.
- The WHILE loop
- The loop check for the WHILE loop using the logical operator AND, the comparison operator <, and parentheses to group the expression.
- The call to the (built-in) procedure WriteF using parameters. Notice the string, the place holders for numbers, \d, and the linefeed, \n.
- Assignments to x and y, adding two to their values.
- The marker for the end of the WHILE loop.
- The marker for the end of the procedure.
To return a value, replace ENDPROC with ENDPROC value
Read more about here.
- Constants - TRUE, FALSE, NIL, ALL, GADGETSIZE, OLDFILE, NEWFILE, STRLEN
- Variables - arg, wbmessage, stdout, conout, stdrast, dosbase, execbase, gfxbase, intuitionbase,
- Functions - \c (Number Character) - \d (Number Decimal) - \h (Number Hexadecimal), \s (String String)
- Functions - \l Left justify in field, \r Right justify in field, \z Set fill character to "0"
- Functions - WriteF, StringF, Out, Inp, ReadStr, FileLength, SetStdOut,
- Functions (Intuition) - OpenW, CloseW, OpenS, CloseS, Gadget, Mouse, MouseX, MouseY, WaitIMessage,
- Functions (Graphics) - Plot, Line, Box, Colour, TextF, SetStdRast, SetTopaz,
- Functions (Maths) - Abs, Even, Odd, Mod, Rnd, RndQ, Shl, Shr, Long, Int, Char, PutLong, PutInt, PutChar,
- Functions (System) - New, Dispose, DisposeLink, CleanUp, CtrlC, FreeStack,
The hardest part when moving from BASIC to C, C++ and E is pointers & strings. E & C deal with strings in almost exactly the same way, so there is no great benefit to E there.
AmigaE's treatment of pointers is far simpler than C's, due to C's design. You have to think very carefully about what kind of pointer is required in case a "&" or "*" needs to be added. While with E there is almost never any such worry.
Plus "PTR TO xxx" seems easier to grasp than "xxx*".
Note that there are some good C guides that explain the principles of strings & pointers, using 'box & arrow' diagrams, which you may still find helpful when learning E.
You can just open workbench.library (version 44 or newer required) and call OpenWorkbenchObjectA() as it is documented in autodocs.
/* DirList3.e */ MODULE 'std/cGUI', 'std/cPath' STATIC app_name = 'DirList' PROC main() DEF dirPath:STRING, dir:PTR TO cDir, dirList:PTR TO cDirEntryList DEF win:PTR TO cGuiWindow, guiLastFile:PTR TO cGuiTextBox, guiOK DEF quit:BOOL, item:PTR TO cGuiItem, entry:PTR TO cGuiFixedListEntry ->describe our app CreateApp(app_name).initDescription('This is a simple PortablE demo.').build() ->scan directory dirPath := ImportDirPath('EnvArc:') NEW dir.new() IF dir.open(dirPath, /*readOnly*/ TRUE) = FALSE THEN Throw("ERR", 'Failed to open directory') dirList := dir.makeEntryList() dir.close() ->build the GUI win := CreateGuiWindow(app_name) win.beginGroupVertical() win.addTextBox('').setState('Below is a list of all the files inside EnvArc:') win.beginFixedList().initSelectableEntries(/*multiSelect*/ TRUE) ->step through each file IF dirList.gotoFirst(/*any0file1dir2*/ 1) REPEAT ->add line for file win.addFixedListEntry(dirList.infoName()) UNTIL dirList.gotoNext(1) = FALSE ENDIF win.endFixedList() guiLastFile := win.addTextBox('The last ticked file:') guiOK := win.addButton('OK') win.endGroup() win.build() ->handle user interaction with GUI quit := FALSE REPEAT item := WaitForChangedGuiItem() IF item = NIL IF win.getCloseRequest() THEN quit := TRUE ELSE IF item = guiOK quit := TRUE ELSE IF item.IsOfClassType(TYPEOF cGuiFixedListEntry) entry := item::cGuiFixedListEntry IF entry.getState() ->(a file was ticked) so tell user which file they just ticked guiLastFile.setState(entry.infoLabel()) ENDIF ENDIF UNTIL quit win.close() FINALLY PrintException() END dirPath, dir ENDPROC
AmigaE works well and integrates with Assembly well also. Just don't go writing shared libraries with it since there are design flaws with the library mode. Also, if you plan on using multiple return codes, keep them in the same source as your application code because the module generation doesn't work right with multiple return codes. Lastly, don't nest the function form of the IF keyword (the AmigaE equivalent of the ? : operators in C). Those are all of the bugs I can think of in the compiler.