Simplest Escher Interpreter?

[cheery]

I'd like to study this language, for that purpose I'd like to write the interpreter and programming environment myself.

Do you have an exact specification I could follow? If not, which documents do I need to read?

[maymounkov]

The implementation is the shortest spec I have other than the doc, for now.

I do encourage writing other interpreters for Escher, for instance for the
browser.

The grammar itself is independent of the gates in the doc. Gates are just
libraries.

And the grammar just says that semantically every reflex is an independent
compute entity that can receive and send value a synchronously on named
places, Called valves.

That's badically it. That's the beauty of it.
The only crucial detail is that a wire remembers the last value sent in
each direction and does not let thru a value if it is identical to the one
before.

If you want more rigour. The implementation is by far the shortest spec.
4000 words. Not even.

Petar

On Tuesday, July 29, 2014, cheery notifications@github.com wrote:

I'd like to study this language, for that purpose I'd like to write the
interpreter and programming environment myself.

Do you have an exact specification I could follow? If not, which documents
do I need to read?

—
Reply to this email directly or view it on GitHub
#6.

[cheery]

Hi Petar

I did study the implementation. I see the reflex and valves. I also see the concept you call "circuit design" in the code and concept of materializing. The NAND-OR switch circuit sort of describes it, but also brings out lot of questions.

The circuit designs aren't active circuits? They're just a design of a reflex. It seems you intend to have reflexes to create, modify and materialize circuit designs. Is the space where the circuits materialize different from place where they are designed?

Can you describe the algorithm that would do the thing you described in the README.md?

Users do not need to explicitly moduralize (sub-divide) their circuits. One could start designing a circuit wiring and the compiler will automatically find sub-patterns that are abstractable as circuits. Which includes non-obvious and/or recursive ones.

How does computer find these sub patterns, especially the recursive ones. when the user keeps working on the wiring?

I'd like to understand the idea of choiceless computing better. You had the bottle cap example, but I did not recognize how it demonstrates that. Spent some time wondering that. Does choiceless mean there's no if else in the circuits?

With the 'escher' you refer to the duality. But I fail to see the biggest thing about this. It looks just like traditional computer programs to me, except that every reflex doesn't contain just one program but all it's duals too. Does it mean something else besides that?

[maymounkov]

Inline:

On 30 July 2014 06:33, cheery notifications@github.com wrote:

Hi Petar

I did study the implementation. I see the reflex and valves. I also see
the concept you call "circuit design" in the code and concept of
materializing. The NAND-OR switch circuit sort of describes it, but also
brings out lot of questions.

The circuit designs aren't active circuits?

This will be clearer in an upcoming checkin. Circuit designs are
data structures of the basic tree type. They are data until you
materialize them. Escher materializes (i.e. runs) top level circuit
definitions
like "main". But others (and there are no examples of this yet)
can stay as data until you feed them into a special gate that materializes
them (kind of like reflection in functional programming languages).

They're just a design of a reflex. It seems you intend to have reflexes to
create, modify and materialize circuit designs. Is the space where the
circuits materialize different from place where they are designed?

I am not sure what you mean. It all happens in the runtime.

Can you describe the algorithm that would do the thing you described in
the README.md?

Users do not need to explicitly moduralize (sub-divide) their circuits.
One could start designing a circuit wiring and the compiler will
automatically find sub-patterns that are abstractable as circuits. Which
includes non-obvious and/or recursive ones.

Yes, in a multi-page academic paper (not written), or in code after a few
months.
This is not a priority for Escher at the moment. This is something
which I plan to do (or help others do) later when Escher gets traction.

You see: I can describe how to accomplish all my claims. But describing it
entails as much work as making it. And making it takes time.
So these fringe features are a matter of patience (I don't get paid for
this work).

Alternatively, you can try to figure it out yourself. It boils down to
inferring
the "types" of data flowing through the valves after watching them being
used
by the user. This is the basic idea. The rest is text book computer science
(Graph algorithms and such.)

How does computer find these sub patterns, especially the recursive ones.

when the user keeps working on the wiring?

(See above)

I'd like to understand the idea of choiceless computing better. You had
the bottle cap example, but I did not recognize how it demonstrates that.
Spent some time wondering that. Does choiceless mean there's no if else
in the circuits?

Choicelessness is not something you need to understand to use Escher.
I put the link to Shelah's paper so that academic (who use a language
different
than yours) can find their way through the ideas. You can skip it.
Otherwise, it is explained in Shelah's paper or in textbooks on model
theory.
There is no shorter explanation. Sorry :( this is the unfortunate nature of
knowledge.
There are no short answers for some things.

With the 'escher' you refer to the duality. But I fail to see the biggest
thing about this. It looks just like traditional computer programs to me,
except that every reflex doesn't contain just one program but all it's
duals too. Does it mean something else besides that?

I would say: Stay away from words you don't understand. Don't be offended.
I put these words "dual", "choiceless", etc. because there are people who
understand them. But they are not necessary. If the language makes sense to
you,
that's all that matters.

In fact, through using Escher you will learn all these concepts eventually,
as opposed to confronting the hard math papers that I had to read in order
to discover a most simple language.

This is the first, obviously incomplete and somewhat rushed, README for
Escher.
As a result, it seems I have not done a good job of making it clear that
some sections are for mathematicians (so they can relate, otherwise they
never look at source) and others are for practitioners.
It's like the README is written in both English and Chinese :)
Both say the same story with different words.

I appreciate your interest!
P

—
Reply to this email directly or view it on GitHub
#6 (comment).

[cheery]

There will be probably shorter, cleaner explanation for the choicelessness than Shelah's paper.

I would be interested about how the circuits behave after materialized. Can user peek inside them when they are running? After materialized, do they stay materialized as long as the program is running? How recursive circuits function?

[maymounkov]

On 30 July 2014 13:08, cheery notifications@github.com wrote:

There will be probably shorter, cleaner explanation for the choicelessness
than Shelah's paper.

You are right. I think there will be. Shelah's paper is relatively recent
and unknown,
but people will pick it up. I personally want to write about the connection
between
choicelessness and linguistics, but this won't happen for many month,
unfortunately.

I would be interested about how the circuits behave after materialized.
Can user peek inside them when they are running?

Yes. (Not implemented.) The entire state of a running circuit is in the
wires.
Recall that each wire remembers the last value sent to it.
Not only programs can be frozen and unfrozen generically,
but one can watch a circuit (with some nice interactive visualization)
side-by-side with the actual execution and peek into the values flowing
through the wires.

After materialized, do they stay materialized as long as the program is
running?

Yes. Just like electrical circuits :)

How recursive circuits function?

There will be a gate that consumes a tree (which represents a circuit
design)
and executes it in its own isolated runtime. Except there will be a way to
feed the values coming out of the valves of the child circuit into the
parent one.

This will likely be done similarly to the way one would implement an array
(or slice).
This would look like a memory chip:
It would have an indexing/addressing valve, and a value valve.
When you set an index to the index valve,
the value valve will fire the value of that element in the slice.
Writing to the value valve will set the value.

In general, electrical engineering intuition for how to design reflex
interfaces
always tends to be the right thing to do.

—

Reply to this email directly or view it on GitHub
#6 (comment).