Re: Monte Language -- wow

--===============2405796070862737987==
Content-Type: multipart/alternative; boundary=001a113ec9943814e8052a177cd6

--001a113ec9943814e8052a177cd6
Content-Type: text/plain; charset=UTF-8

On 24 January 2016 at 13:56, Mark S. Miller <[email protected]> wrote:
> I just stumbled across the Monte language
> http://monte.readthedocs.org/en/latest/index.html
>
> Wow. Have we discussed it here before? I don't remember that we have, but it
> is hard to believe that we have not.

Hi! Corbin and I have been keeping this quiet until we had something
close to parity with E-on-Java.
Monte is a close cousin of E, using Kernel-E with some minor
extensions. We aim to bring the benefits of the years of
research and design put into E to a modern implementation suitable for
production use. Our chief semantic differences are
the addition of named arguments and parameters to the kernel language,
and switching from internal iteration to external.
The expanded syntax uses Python/Haskell's indentation rules though
braces and semicolons are still available. We have a
runtime with a JIT compiler, written in RPython (the restricted python
subset PyPy's runtime is written in). The lexer
/parser/expander stack is self-hosted, and currently the runtime
internally compiles Kernel-Monte to a bytecode
representation.

We implement E-on-CL style guard-based auditing, and have a working
auditor for DeepFrozen and Transparent. Current
development focus is on a basic module system largely similar to
ES6's. We haven't pursued CapTP yet but implement vats,
async networking and IPC (via libuv), crypto primitives (via
libsodium), and proxy refs.

Performance has received relatively little attention since we're still
covering basic features, but it's currently fast
enough that running our precompile step (parsing code, expanding,
dumping a binary AST representation) isn't too tedious.

The name, of course, I stole from a post you made here in 2004.

The code should be fairly easy to understand for anyone comfortable
with E-on-Java's internals:

https://github.com/monte-language/typhon

We welcome contributions, bug reports, and puzzled questions. :)

--001a113ec9943814e8052a177cd6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><pre>On 24 January 2016 at 13:56, Mark S. Miller &lt;<a hr=
ef=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:
&gt; I just stumbled across the Monte language
&gt; <a href=3D"http://monte.readthedocs.org/en/latest/index.html">http://m=
onte.readthedocs.org/en/latest/index.html</a>
&gt;
&gt; Wow. Have we discussed it here before? I don&#39;t remember that we ha=
ve, but it
&gt; is hard to believe that we have not.

Hi! Corbin and I have been keeping this quiet until we had something close =
to parity with E-on-Java.
Monte is a close cousin of E, using Kernel-E with some minor extensions. We=
 aim to bring the benefits of the years of
research and design put into E to a modern implementation suitable for prod=
uction use. Our chief semantic differences are
the addition of named arguments and parameters to the kernel language, and =
switching from internal iteration to external.
The expanded syntax uses Python/Haskell&#39;s indentation rules though brac=
es and semicolons are still available. We have a
runtime with a JIT compiler, written in RPython (the restricted python subs=
et PyPy&#39;s runtime is written in). The lexer
/parser/expander stack is self-hosted, and currently the runtime internally=
 compiles Kernel-Monte to a bytecode
representation.

We implement E-on-CL style guard-based auditing, and have a working auditor=
 for DeepFrozen and Transparent. Current
development focus is on a basic module system largely similar to ES6&#39;s.=
 We haven&#39;t pursued CapTP yet but implement vats,
async networking and IPC (via libuv), crypto primitives (via libsodium), an=
d proxy refs.

Performance has received relatively little attention since we&#39;re still =
covering basic features, but it&#39;s currently fast
enough that running our precompile step (parsing code, expanding, dumping a=
 binary AST representation) isn&#39;t too tedious.

The name, of course, I stole from a post you made here in 2004.

The code should be fairly easy to understand for anyone comfortable with E-=
on-Java&#39;s internals:<br><br><a href=3D"https://github.com/monte-languag=
e/typhon">https://github.com/monte-language/typhon</a><br><br>We welcome co=
ntributions, bug reports, and puzzled questions. :)</pre></div>

--001a113ec9943814e8052a177cd6--

--===============2405796070862737987==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang

--===============2405796070862737987==--