Re: Changing the name and focus of this group from WebAssembly and binary code to WebCore etc and source code.

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