- From: JS Stats <info@jsstats.com>
- Date: Fri, 27 Nov 2015 14:47:51 +1100
- To: public-webassembly@w3.org
The name WebCore seems well taken. Another suggestion: WebBitScript. A quick US trademark search found nothing for bit-script, nor web-bit-script, but web-script was popular. Expanding on the source compression efficiency, I believe it could be competitive with whatever wasm could achieve. The key would be to have a canonical text source style that compresses most efficiently, and any deviation might increase compressed size to remain lossless. If the producer wanted maximum compression they would firstly canonicalize the style of their source text, and this could just be a compression option to ignore non-canonical styling and text. There could be a canonical white space source convention. The canonical text style need not be stripped of white space, rather it could use standard indentation etc. The same principle might be used for some other source elements such as labels that might have a canonical minified format while the compression could still degrading gracefully if some labels were not in canonical form. For example the producer might choose to not canonicalize function names but to canonicalize block labels and local variables. For example the producer might choose to keep some common local variable names, such as a stack pointer etc, which might compress very well given their repetition. The canonical form might include specific support for comments, so that the consumer knowns the difference between comments and non-canonical styling. Multiple text source formats (JS-like, minified JS-like, s-exp, etc) might be supported, and if in canonical style then they could be converted to another canonical format without loss. Source with non-canonical text would obviously not convert without loss but could still convert to a canonical style. Anyway, it seems quite possible to focus on a primitive 'source' code without compromising the goals of being a 'portable, size- and load-time-efficient format suitable for compilation to the web'. The difference seems to just be what intent people want: - a binary virtual machine code, with a design and language that parallels compilation to native machine code, and might invoke the parallels of 'disassembly' and 'reverse engineering' which might disadvantage web user rights but advance some agendas. - versus a clear source code story for the web, which is my strong preference. Regards Douglas Crosher On 11/26/2015 06:25 PM, JS Stats wrote: > I would like to make the case to the members to consider changing the > focus of this group from the development of a binary code to a source > code with a binary encoding. The difference might not sound significant > at first but it might make a significant difference to the intent of > code deployed to the web in binary format. > > In the current case source code is 'compiled' or 'assembled' into the > binary format and deployed in binary format. With this focus the > developers might be tempted to abandon any claim to the binary encoding > being related to the source, and for example move to a linear virtual > machine code without expressions or structured flow control etc. > > While it might be possible to 'view-source' the deployed code it might > be consider 'disassembly' or 'reverse engineering' which are very loaded > terms for IP. > > I believe that although the operators being developed are primitive and > close to the hardware, that these can still be used in a structured > source code with expressions and local variables etc to make the code > more readable and easier to write. A binary encoding would still be > developed that would be a one-to-one reversible encoding of the source > (basically a lossless compression of the source). I believe this could > still be a good target for the use case of a compilation target which > seems to be the current focus. > > I have been working away at trying to use type derivation to help > eliminate bounds checking, and there has been another recent proposal by > sunfish to use some loop analysis to help eliminate bounds checks too, > and while I don't have anything concrete I suspect this will be much > easier to define in structured code. For example, a common case is to > define a local constant variable with a typed that can be derived such > as masking a value or asserting its bounds. > > The new name would remove 'Assembly' and make it clear this is a source > code although primitive. For example WebCore if it is not taken. The > Specification language would change it's emphasis to being a source > code, while still supporting the use case of being a compilation target. > > Would there be any support for such a re-focusing of the group, or are > the majority of people wanting a web machine code binary format to > compile to? > > Regards > Douglas Crosher > >
Received on Friday, 27 November 2015 03:48:20 UTC