External types - Revision history

Dkearns: s/LibertyEiffel/Liberty Eiffel/

2016-07-03T06:50:00Z

s/LibertyEiffel/Liberty Eiffel/

← Older revision		Revision as of 08:50, 3 July 2016
Line 37:		Line 37:
	x = 3.14, c = 6		x = 3.14, c = 6

−	= Embedding external types in ~~LibertyEiffel~~ =	+	= Embedding external types in Liberty Eiffel =
	There are currently two competing mechanisms. Their expressivity is roughly the same (when you have one it is easy to emulate the other).		There are currently two competing mechanisms. Their expressivity is roughly the same (when you have one it is easy to emulate the other).

Line 192:		Line 192:

	= Helper functions =		= Helper functions =
−	It must be possible for plugin writer to supply functions to help the ~~LibertyEiffel~~ runtime implement a few of ANY's standard routines: standard_copy, deep_twin, standard_is_equal, deep_is_equal.	+	It must be possible for plugin writer to supply functions to help the Liberty Eiffel runtime implement a few of ANY's standard routines: standard_copy, deep_twin, standard_is_equal, deep_is_equal.

	== Optional vs. mandatory helpers ==		== Optional vs. mandatory helpers ==

Hzwakenberg at 13:21, 7 September 2014

2014-09-07T13:21:51Z

← Older revision		Revision as of 15:21, 7 September 2014
Line 1:		Line 1:
		+	[[Category: Interfacing]]
	todo: describe what actually IS implemented and update [[Externals]]		todo: describe what actually IS implemented and update [[Externals]]

Hzwakenberg at 19:44, 5 September 2014

2014-09-05T19:44:13Z

← Older revision		Revision as of 21:44, 5 September 2014
Line 1:		Line 1:
	todo: describe what actually IS implemented and update [[Externals]]		todo: describe what actually IS implemented and update [[Externals]]

−	[[Category:Smarteiffel]]
	The syntax will have to be flexible enough to work for any reasonable external language, not just C (e.g. Java). No provision is made for embedding variable-sized external types.		The syntax will have to be flexible enough to work for any reasonable external language, not just C (e.g. Java). No provision is made for embedding variable-sized external types.

Line 37:		Line 36:
	x = 3.14, c = 6		x = 3.14, c = 6

−	= Embedding external types in ~~SmartEiffel~~ =	+	= Embedding external types in LibertyEiffel =
	There are currently two competing mechanisms. Their expressivity is roughly the same (when you have one it is easy to emulate the other).		There are currently two competing mechanisms. Their expressivity is roughly the same (when you have one it is easy to emulate the other).

Line 192:		Line 191:

	= Helper functions =		= Helper functions =
−	It must be possible for plugin writer to supply functions to help the ~~SmartEiffel~~ runtime implement a few of ANY's standard routines: standard_copy, deep_twin, standard_is_equal, deep_is_equal.	+	It must be possible for plugin writer to supply functions to help the LibertyEiffel runtime implement a few of ANY's standard routines: standard_copy, deep_twin, standard_is_equal, deep_is_equal.

	== Optional vs. mandatory helpers ==		== Optional vs. mandatory helpers ==

Ramack at 22:19, 23 May 2014

2014-05-23T22:19:22Z

← Older revision		Revision as of 00:19, 24 May 2014
Line 1:		Line 1:
		+	todo: describe what actually IS implemented and update [[Externals]]
		+
	[[Category:Smarteiffel]]		[[Category:Smarteiffel]]
	The syntax will have to be flexible enough to work for any reasonable external language, not just C (e.g. Java). No provision is made for embedding variable-sized external types.		The syntax will have to be flexible enough to work for any reasonable external language, not just C (e.g. Java). No provision is made for embedding variable-sized external types.

Ramack at 21:32, 5 March 2013

2013-03-05T21:32:24Z

← Older revision		Revision as of 23:32, 5 March 2013
Line 1:		Line 1:
−	[[Category:~~SmartEiffel~~]]	+	[[Category:Smarteiffel]]
	The syntax will have to be flexible enough to work for any reasonable external language, not just C (e.g. Java). No provision is made for embedding variable-sized external types.		The syntax will have to be flexible enough to work for any reasonable external language, not just C (e.g. Java). No provision is made for embedding variable-sized external types.

Ramack at 20:54, 4 March 2013

2013-03-04T20:54:30Z

← Older revision		Revision as of 22:54, 4 March 2013
Line 1:		Line 1:
		+	[[Category:SmartEiffel]]
	The syntax will have to be flexible enough to work for any reasonable external language, not just C (e.g. Java). No provision is made for embedding variable-sized external types.		The syntax will have to be flexible enough to work for any reasonable external language, not just C (e.g. Java). No provision is made for embedding variable-sized external types.

Ramack: 36 revisions: initial import from SamrtEiffel Wiki - The Grand SmartEiffel Book

2013-03-03T21:04:41Z

36 revisions: initial import from SamrtEiffel Wiki - The Grand SmartEiffel Book

New page

The syntax will have to be flexible enough to work for any reasonable external language, not just C (e.g. Java). No provision is made for embedding variable-sized external types.

= The plug-in for the examples =
For syntactic experiments, we'll assume the following C files are used.

'''my_struct.h''':
typedef struct {
double x;
int c;
} my_struct;

'''my_struct.c''':
#include "my_struct.h"
use (my_struct *x) {
x->x = 3.14;

if(x->c == 0) x->c = 5;
else x->c++;

printf("x = %f, c = %d\n", x->x, x->c);
}

use_copy (my_struct x) {
x.x = 3.14;

if(x.c == 0) x.c = 5;
else x.c++;

printf("x = %f, c = %d\n", x.x, x.c);
}

The program should print
x = 3.14, c = 5
x = 3.14, c = 6

= Embedding external types in SmartEiffel =
There are currently two competing mechanisms. Their expressivity is roughly the same (when you have one it is easy to emulate the other).

== External attributes ==
The "external" keyword is used as a type name to tell the Eiffel compiler that an attribute should be represented by a user-specified external type. (The precise syntax is not fixed: the attribute may look better with a "plug_in" manifest string or an "is" keyword)

class SHOW

creation
make

feature
make is
do
use($ext)
use_copy(ext)
end

use (x: POINTER) is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
feature_name: "use"
}"
end

use_copy (x: like ext) is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
feature_name: "use_copy"
}"
end

ext: external
alias "{
location: "./"
module_name: "struct"
attribute_type: "my_struct"
}"
end
end

== External classes ==
A special marker is used to tell the Eiffel compile that a class should be represented by a user-specified external type. Methods of that class can be implemented by passing Current as a parameter to external routines. Whether Current is passed by copy or by reference could be determined by the reference/expanded status of the external class.

Issues:
* Forces the programmer to write one class for each external type they want to wrap

expanded class SHOW

external "plug_in"
alias "{
location: "./"
module_name: "struct"
attribute_type: "my_struct"
}"

creation
make

feature
make is
do
-- Memory is zeroed, so we probably don't need to initialize x and
-- c. If we do, we'll have to call a C function to do it.
use($Current)
use_copy(Current)
end

use (x: POINTER) is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
feature_name: "use"
}"
end

use_copy (x: like Current) is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
feature_name: "use_copy"
}"
end

end

Two variants (along with possible hybrids)

=== Living at the edge of the Eiffel world ===
* External classes always insert exactly ANY (and don't inherit from anything)
* they can't be inherited from (and probably not inserted either)
* they can't have ordinary Eiffel attributes.

=== Ordinary Eiffel citizens ===
* External classes can have Eiffel attributes
* External classes can be inherited from and inserted
* External classes ca, inherit from or insert other classes

Likely to result in a very unclean implementation (need either to reorder the struct so that the external part is at the beginning, or to represent references to such objects as pointers 'into' the object (rather than to its head), or to mess with the pointer when passing it to the C world). Even more mess likely in case of multiple external parents.

== Inline external classes ==
Ok, so there are actually three mechanisms, but this one is hybrid between the previous two (give the external attribute an Eiffel type that doesn't need to be defined anywhere else)

With this approach we can even allow this type for external features, which would solve the pass-by-value/reference question: do a copy or use a pointer to it.

Issues:
* What is the scope of such a type? Only visible in the class it is written in? Are two external types with the same "name" in different classes the same?

class SHOW
creation
make

feature
make is
do
use($ext)
copy_use(ext)
end

use (x: POINTER) is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
feature_name: "use"
}"
end

use_copy (x: like ext) is
-- Here a copy of x would be passed
external "plug_in"
alias "{
location: "./"
module_name: "struct"
feature_name: "use_copy"
}"
end

ext: external MY_STRUCT is -- inline declaration of external type
external "plug_in"
alias "{
location: "./"
module_name: "struct"
attribute_type: "my_struct"
}"
end
end

= Helper functions =
It must be possible for plugin writer to supply functions to help the SmartEiffel runtime implement a few of ANY's standard routines: standard_copy, deep_twin, standard_is_equal, deep_is_equal.

== Optional vs. mandatory helpers ==
Putting helpers could be made mandatory or optional (if a reasonable default can be found).

=== Provide defaults where possible ===
A reasonable default is to assume that the external types are shallow, so the helpers for deep_twin and deep_is_equal can be made optional (but the plugin writer can provide them if he wants a special treatment)

Some backends may also be able to provide reasonable default helpers for standard_is_equal and standard_copy, making them optional. For other backends, the plugin-writer may have to provide one or both of the helpers. That may seem inconsistent but it's not really a problem as a plugin needs to be tested with every back-end it is supposed to work with anyway, so missing helpers will be detected. The C backend can generate a default copy function (using memcpy and sizeof), but it can't genereate a default equality testing function (the == operator can't be applied to structures, memcmp is unacceptable because two structures may differ only by garbage in the padding).

=== Don't provide defaults at all ===
Just throw an error if one of the helpers is missing.

=== Provide silly defaults, emit a warning ===
The default helpers just crash (with a run time stack if possible). Emit a warning if the plugin writer doesn't provide the required helpers.

== Granularity ==
The granularity could be one pack of helpers per Eiffel class or one pack of helpers per external type (obvisouly there's no difference if the "external classes" implementation is chosen).

=== Eiffel class granularity ===
The helpers are eiffel functions with "magical" names.

=== External type granularity ===
The helper's names appear inside the "alias" clause.

= Relevance to backends =
Depending on the backend, the mechanism can add real expressivity or be of the "sugar" variety.

== C ==
This is the only way to embed C structures into Eiffel objects. It also makes it easier to interact with C types that are typedef'd or #defined to a basic type that is not known in advance (up to now, plugin-writers had to guess if it would be e.g. an INTEGER_32 or an INTEGER_64).

== Java ==
All the basic types are already wrapped and there are no typedefs or #defines. Finally, it is not possible to embed Java objects, so the gain would be limited. At least it means that we ''could'' rewrite the wrappers for the basic types using external types if we had the time (less magic is always a good thing!), and the we can embed more precise references to java objects than just "Object".

Cadrian: question

2007-07-18T13:12:30Z

question

New page

There are currently two competing mechanisms. Their expressivity is roughly the same (when you have one it is easy to emulate the other).

For syntactic experiments, we'll assume the following C files are used but the syntax will have to be flexible enough to work for other external languages (e.g. Java).

'''my_struct.h''':
typedef struct {
double x;
int c;
} my_struct;

'''my_struct.c''':
#include "my_struct.h"
use (my_struct *x) {
x->x = 3.14;

if(x->c == 0) x->c = 5;
else x->c++;

printf("x = %f, c = %d\n", x->x, x->c);
}

The program should print
x = 3.14, c = 5
x = 3.14, c = 6

= External attributes =
A special marker is used to tell the Eiffel compiler that an attribute should be represented by a user-specified external type. The only meaningful thing that can be done with it is passing it as a parameter to external routines.

Issues:
* what is the Eiffel type of the attribute?
* when "passing" the attribute, do we pass a copy or a reference?

Two suggested versions

== Faux procedures ==
class SHOW

creation
make

feature
make is
do
use($ext)
use($ext)
end

use(x: POINTER) is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
feature_name: "use"
}"
end

ext is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
attribute_type: "my_struct"
}"
end
end

== Faux pointers ==
class SHOW

creation
make

feature
make is
do
use(ext)
use(ext)
end

use(x: POINTER) is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
feature_name: "use"
}"
end

ext: POINTER is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
attribute_type: "my_struct"
}"
end
end

= External classes =
A special marker is used to tell the Eiffel compile that a class should be represented by a user-specified external type. Methods of that class can be implemented by passing Current as a parameter to external routines. Whether Current is passed by copy or by reference could be determined by the reference/expanded status of the external class.

Issues:
* Forces the programmer to write one class for each external type they want to wrap
* It wouldn't be possible to inherit from/insert that kind of class
* such classes should not inherit/insert other classes (ANY?)
* Implementing some of ANY's operations for external types might be difficult
* How are native eiffel attributes in such a class handled?
** Forbid them is not nice, since this may yield to to need to write two classes in special cases, also this would be a special case, which is not nice in general.
** Allowing, would force a dedicated ordering in the generated struct for the eiffel object

expanded class SHOW

external "plug_in"
alias "{
location: "./"
module_name: "struct"
attribute_type: "my_struct"
}"

creation
make

feature
make is
do
-- Memory is zeroed, so we probably don't need to initialize x and
-- c. If we do, we'll have to call a C function to do it.
use($Current)
use($Current)
end

use(x: POINTER) is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
feature_name: "use"
}"
end

end

= Inline external classes =
Ok, so there are actually three mechanisms, but this one is hybrid between the previous two (give the external attribute an Eiffel type that doesn't need to be defined anywhere else)

With this approach we can even allow this type for external features, which would solve the pass-by-value/reference question: do a copy or use a pointer to it.

Issues:
* What is the scope of such a type? Only visible in the class it is written in? Are two external types with the same "name" in different classes the same?
* What is the use of the type name? I'd just ommit it (<tt>ext: external is ...</tt>) --[[User:Cadrian|Cyril]] 15:12, 18 Jul 2007 (CEST)

class SHOW
creation
make

feature
make is
do
use($ext)
use($ext)
end

use(x: POINTER) is
external "plug_in"
alias "{
location: "./"
module_name: "struct"
feature_name: "use"
}"
end

ext: external MY_STRUCT is -- inline declaration of external type
external "plug_in"
alias "{
location: "./"
module_name: "struct"
attribute_type: "my_struct"
}"
end
end

Ramack: added a few comments

2007-07-17T14:17:32Z

added a few comments

New page

There are currently two competing mechanisms. Their expressivity is roughly the same (when you have one it is easy to emulate the other).

= External attributes =
A special marker is used to tell the Eiffel compiler that an attribute should be represented by a user-specified external type. The only meaningful thing that can be done with it is passing it as a parameter to external routines.

Issues:
* what is the Eiffel type of the attribute?
* when "passing" the attribute, do we pass a copy or a reference?

= External classes =
A special marker is used to tell the Eiffel compile that a class should be represented by a user-specified external type. Methods of that class can be implemented by passing Current as a parameter to external routines. Whether Current is passed by copy or by reference could be determined by the reference/expanded status of the external class.

Issues:
* Forces the programmer to write one class for each external type they want to wrap
* It wouldn't be possible to inherit from/insert that kind of class
* such classes should not inherit/insert other classes (ANY?)
* Implementing some of ANY's operations for external types might be difficult
* How are native eiffel attributes in such a class handled?
** Forbid them is not nice, since this may yield to to need to write two classes in special cases, also this would be a special case, which is not nice in general.
** Allowing, would force a dedicated ordering in the generated struct for the eiffel object

= Inline external types =
I think we should not call them inline external classes [[User:Ramack|Ramack]] 16:17, 17 Jul 2007 (CEST)
Ok, so there are actually three mechanisms, but this one is hybrid between the previous two (give the external attribute an Eiffel type that doesn't need to be defined anywhere else)

With this approach we can even allow this type for external features, which would solve the pass-by-value/reference question: do a copy or use a pointer to it.

Issues:
* What is the scope of such a type? Only visible in the class it is written in? Are two external types with the same "name" in different classes the same?