OpenEuphoria

2. Re: Euphoria on non-Intel CPUs

• Posted by Vinoba Mar 16, 2011
• 2165 views

I am afraid, unlike you, euphoria is not my main platform. I was heavily with Clipper and then Harbour and am still more inclined to use a database language with my current project. I am currently developing one project using Harbour 2.1 with Minigui version 1.94 Before that I was working with APL. Euphoria is (or rather was) close to APL, but it has deviated and has become totally restricted by C language constraints and methods. Using different CPUs and multi-platform development is currently possible using C, C plus and C#. I dislike all flavours of C.

I have developed heavily in Intel Assemblers, and am working on a Virtual CPU (as a hobby project). I have worked using BCX, Visual Basic, and autoit. I have done assembler level translation or rather transformations (and been paid for it) between 80386 and 68000.

Because Internet is king, I worked using HTML 4, and tried Java, but was shocked by the inefficiencies of some of the oop. Perhaps I am getting old and unable to learn this. In fact, it is far better to restrict COMPLETELY to procedural language, and because of the proliferation of functions to use function names with three letter prefixes to denote groups.

I always advocate a simple dyadicR or monadicR syntax (ref Iverson) i.e. one or two arguments to a function with always a result returned, and I do not like the concept of niladic and no result functions (such as procedures in many of the languages) - I would always return the argument supplied as a result if no other result is available. The reason is quite simple - if there is a result it can become an argument to the next function in a pipe. For the multiple arguments required by Windows calls, e.g. Creating a window, - I would advocate an ability to precreate an object variable with all the specs, and the ability to pass a single object argument for the creation of a Window, even if this means exploding the Object at precompile to pass it to the OS as they want it.

Well you got a bigger reply than you bargained for.

I am in a Euphoria forum, and do not wish to start a discussion on other languages or methodologies, except where a slight change in thinking might help this language. The two discussion I sort of got more involved in were

1. Unicode - a much needed improvement, and

2. removal of data type or size in a function definition and migrate it to the execution or pre-execution level. This concept can only be understood properly by people who have written at a low level to create a language - AN ACTIVITY I HAVE DONE IN MY LIFE.

For you it is best to know that (IN MY OPINION) less restrictions and formal syntax at the programmer level is better, and more hand-holding of the end user in the programs written by the application programmer is a good idea.

I have already given my opinion to the people who matter and I consider this issue closed.