You have gone to some length to at least define the underlying language structure, I guess the operational semantics are coming later. I think this is a good thing.
But what about the semantics of the graphics? Although the representations are as yet undecided, if you are going down the formal route, you should at least have a strategy for binding graphics to semantics, formally.
Furthermore, you mentional representational independence. Does this imply a multitude of different representations, and in what space/formal system are they expressed?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> But what about the semantics of the graphics?
> you should at least have a strategy for
> binding graphics to semantics, formally
Mapping to the formal semantics isn't as important for notations as it is for more machine-centric representations. The reason for this is that one can always observe the effects of UI actions in the kernel; it's analogous to the reason one doesn't need to specify a formal semantics for a text editor in order to edit Scheme.
One could formalize the actions of a user interface on an Eidola program. That might be useful, but it is not necessary.
> you mention representational independence.
> Does this imply a multitude of different
> representations, and in what space/formal
> system are they expressed?
"Representation independence" means that many physical representations (object models, file formats, etc) all map to the formal language definition. Physical representations are not necessarily themselves expressed in formal spaces -- though they could be for the purpose of verifying the mapping.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're absolutely right, a formalization of the notation is not at all *necessary*. In fact, I have a fairly dim view about current visual language theory, and it's not really going to help you. But, others argue that for the future formalism is the only route to robust visual language tools.
However some formalisms, such as grammars, are absolutely essential for textual languages, you cannot implement one without one.
But, formalization of your kernerl is not *necessary* either. Most practical languages do not adhere to formal semantics, just informal ones (e.g. Java/C++/Perl/Python/bash/Tcl/VB/Delphi). The slightly less practical ones (Scheme/ML/Haskell/Prolog) are much better at obeying semantics. However, you want practical AND formal, good luck!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's true that though Delphi, Java, etc. are fairly well-specified, they doesn't need to be fully formalized. The presence of a fixed grammar and a reference implementation don't leave much wiggle room for other representations to go astray.
The reason formalization of the kernel is necessary for Eidola is that, when there is no canonical language representation, it's much harder to maintain consistency. It's not possible to provide a single standard compatibility suite anymore; or rather, it's possible, but the tests have to be mapped into each new representation. And how does the mapping happen? The purpose of the formal model of Eidola is to make that clear.
We can quibble on "necessary", but representation independence without formalization is, if not impossible, at least highly impractical.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have gone to some length to at least define the underlying language structure, I guess the operational semantics are coming later. I think this is a good thing.
But what about the semantics of the graphics? Although the representations are as yet undecided, if you are going down the formal route, you should at least have a strategy for binding graphics to semantics, formally.
Furthermore, you mentional representational independence. Does this imply a multitude of different representations, and in what space/formal system are they expressed?
> But what about the semantics of the graphics?
> you should at least have a strategy for
> binding graphics to semantics, formally
Mapping to the formal semantics isn't as important for notations as it is for more machine-centric representations. The reason for this is that one can always observe the effects of UI actions in the kernel; it's analogous to the reason one doesn't need to specify a formal semantics for a text editor in order to edit Scheme.
One could formalize the actions of a user interface on an Eidola program. That might be useful, but it is not necessary.
> you mention representational independence.
> Does this imply a multitude of different
> representations, and in what space/formal
> system are they expressed?
"Representation independence" means that many physical representations (object models, file formats, etc) all map to the formal language definition. Physical representations are not necessarily themselves expressed in formal spaces -- though they could be for the purpose of verifying the mapping.
You're absolutely right, a formalization of the notation is not at all *necessary*. In fact, I have a fairly dim view about current visual language theory, and it's not really going to help you. But, others argue that for the future formalism is the only route to robust visual language tools.
However some formalisms, such as grammars, are absolutely essential for textual languages, you cannot implement one without one.
But, formalization of your kernerl is not *necessary* either. Most practical languages do not adhere to formal semantics, just informal ones (e.g. Java/C++/Perl/Python/bash/Tcl/VB/Delphi). The slightly less practical ones (Scheme/ML/Haskell/Prolog) are much better at obeying semantics. However, you want practical AND formal, good luck!
It's true that though Delphi, Java, etc. are fairly well-specified, they doesn't need to be fully formalized. The presence of a fixed grammar and a reference implementation don't leave much wiggle room for other representations to go astray.
The reason formalization of the kernel is necessary for Eidola is that, when there is no canonical language representation, it's much harder to maintain consistency. It's not possible to provide a single standard compatibility suite anymore; or rather, it's possible, but the tests have to be mapped into each new representation. And how does the mapping happen? The purpose of the formal model of Eidola is to make that clear.
We can quibble on "necessary", but representation independence without formalization is, if not impossible, at least highly impractical.