Wiki Diff RoadmapBeyond, revision #5 to tip
= Roadmap Beyond =
<<TOC heading=yes>>
This page documents ideas for improvements to Euphoria beyond the current release in development. It's currently speculative, and nothing is final. This is a place to catalog interesting ideas for future development.
* Object oriented programming or some other type of structured data access for native euphoria data
* Dynamic code evaluation, including using an embedded interpreter
* Integration of compiled libraries with interpreted code
* Compile a euphoria include as a dll.
** Translator adds a function that returns data about the public / exported routines, which the interpreter adds to the symbol table as special euphoria routines
** User can call compiled routines like normal euphoria routines, and the interpreter handles the call transparently
** Possibly use ##ifdef##s to determine whether regular interpreted or compiled library to be used (if available)
** Add a lib/ dir in the euphoria directory structure as a place for the compiled libs to live, or possibly specify other locations through config file
* ##var_id## capabilities similar to current ##routine_id##, but allowing manipulation of euphoria variables by reference
* Co-routines / Generators / Iterators
* Exception handling
* Structure library (i.e., C structures)
** SquareBracketDereferencing (some ideas on how to implement C structures)
* Implied routine_id or functions as first class objects
* Named parameters: function abc(sequence name="John", integer age=30) ... abc(age=18)
* Sequence slicing on function returns: def = abc()[1..3]
* Multiple assignment on return: ~{a,b,c} = xyz() -- xyz returns {"",0,"toe"}
* [[varadic|Varadic arguments]] (variable number of arguments on a call). function xxx( object a ... )
* Move the map functionality to the back end.
* Change the ##if## and ##while## statements to accept a boolean expression rather than an atom expression. This would allow code such as ## if fieldA = "name" then ... ##
* A replacement for ifdef which works more like normal EUPHORIA code. And has declare before use. [[preprocessor_if]]
* Nested routines. The ability to declare a routine inside another routine such that the nested routine's scope is its enclosing routine.
= Roadmap for Euphoria beyond 4.0 =
This page documents ideas for improvements to euphoria after 4.0. It's currently speculative, and nothing is final. This is a place to catalog interesting ideas for future development.
* Object oriented programming or some other type of structured data access for native euphoria data
* Dynamic code evaluation, including using an embedded interpreter
* Integration of compiled libraries with interpreted code
* Compile a euphoria include as a dll.
** Translator adds a function that returns data about the public / exported routines, which the interpreter adds to the symbol table as special euphoria routines
** User can call compiled routines like normal euphoria routines, and the interpreter handles the call transparently
** Possibly use ##ifdef##s to determine whether regular interpreted or compiled library to be used (if available)
** Add a lib/ dir in the euphoria directory structure as a place for the compiled libs to live, or possibly specify other locations through config file
* ##var_id## capabilities similar to current ##routine_id##, but allowing manipulation of euphoria variables by reference
* Co-routines / Generators / Iterators
* Exception handling
* Structure library (i.e., C structures)
* Tail recursion
* Nested routines
* Implied routine_id or functions as first class objects
<<TOC heading=yes>>
This page documents ideas for improvements to Euphoria beyond the current release in development. It's currently speculative, and nothing is final. This is a place to catalog interesting ideas for future development.
* Object oriented programming or some other type of structured data access for native euphoria data
* Dynamic code evaluation, including using an embedded interpreter
* Integration of compiled libraries with interpreted code
* Compile a euphoria include as a dll.
** Translator adds a function that returns data about the public / exported routines, which the interpreter adds to the symbol table as special euphoria routines
** User can call compiled routines like normal euphoria routines, and the interpreter handles the call transparently
** Possibly use ##ifdef##s to determine whether regular interpreted or compiled library to be used (if available)
** Add a lib/ dir in the euphoria directory structure as a place for the compiled libs to live, or possibly specify other locations through config file
* ##var_id## capabilities similar to current ##routine_id##, but allowing manipulation of euphoria variables by reference
* Co-routines / Generators / Iterators
* Exception handling
* Structure library (i.e., C structures)
** SquareBracketDereferencing (some ideas on how to implement C structures)
* Implied routine_id or functions as first class objects
* Named parameters: function abc(sequence name="John", integer age=30) ... abc(age=18)
* Sequence slicing on function returns: def = abc()[1..3]
* Multiple assignment on return: ~{a,b,c} = xyz() -- xyz returns {"",0,"toe"}
* [[varadic|Varadic arguments]] (variable number of arguments on a call). function xxx( object a ... )
* Move the map functionality to the back end.
* Change the ##if## and ##while## statements to accept a boolean expression rather than an atom expression. This would allow code such as ## if fieldA = "name" then ... ##
* A replacement for ifdef which works more like normal EUPHORIA code. And has declare before use. [[preprocessor_if]]
* Nested routines. The ability to declare a routine inside another routine such that the nested routine's scope is its enclosing routine.
