How is this not vapowave?

Message ID
DKIM signature
Download raw message
Badt, how is what you propose isn't simply vaporwave?

You keep on saying logos, logos all the time but what is it?

There is no EBNF specification to my knowledge. At least you
didn't bother to share one. There's no implementation, or a
single Github repository associated with this project, apart
from some vague blog posts?

Don't get me wrong, what you propose is highly interesting.

But there's not much for us to discuss.

Best regards,
Message ID
<p3WMN-omKOUNpMNymtihXGOmfKlcgxmU3UYmkqqnlS_Q7L-9uasDfrwBLzgNVHmCaVNNCtxxgA7qAFLwmjbPsby2iOjO4NLhpbOM1AjDsKo=@protonmail.com> (view parent)
DKIM signature
Download raw message
Hello Ivan,

Your feedback is 100% valid and in fact EBNF is our top priority at the

There's some 4000 lines of Go code in my internal logos codebase, but
most of it is outdated as it relates to the outdated version of the
language informal specification [1].

I had multiple EBNF drafts and auto-generated parsers for that matter,
but none of them are particularly good. What's changed a lot is the
newly introduced bargaining semantic, which is supposed to effectively
solve incapsulation.

There isn't much use in EBNF spec anyway, because much of the parsing
ability is language-dependent e.g. logos is designed in such a way that
both lexer and a parser can be built for any base language, while still
being able to provide equivilent ASTs.

What's settled is the set of atomic signs:

	Actor	{ System actor capable of speach. }
	Int		{ Whole 64-bit number. }
	Real	{ Arbitrary-precision float. }
	Rune	{ Unicode codepoint.[2] }
	X list	{ Ordered list of X. }
	String  { Rune list. }
	K -> V	{ (Map.) For each K there's a V. }
	Enigma	{ Any kind of secret or ciphertext. }
	Alien	{ A hard link to outside discourse. }

There's a set of atomic propositions defined for the aforementioned
atomic signs, and I will skip it for now.

But composite signs— these I'm not so sure about.

In programming, we simply choose to reason about data structures, such
as structs, or classes, or monads, for that matter. There's this idea of
elevated worlds[3] in functional programming which I believe describes
the dilemma perfectly.

The programming language design people literally get high from reasoning
about higher and higher type hierarchies; it gets very ridiculous, there
are memes about this kind of thing.

I believe there's no such thing as object, or function— for that matter.

From the pure logical perspective, there can only be signs and a set of
propositions defined over these signs —no more, no less. At some very
fundamental level, your language can't be too complicated, at that level
it's all very straight-forward.

And that is what 'object' really is— an elaborate illusion, a bunch of
seemingly related propositions that got associated with each other in a
kaleidoscope of emerging meaning.

Yet us people, we think in composition. One thing goes into another, A
consists of B, C. This is what's expected and that's how language works,
it seems.

Composing pairs is easy: you just bring a 'tuple' for a ride:

	XY := (real, real).
	XY <- (65.360, 42.420)!

Easy enough, but what if optionally I want to track Y-axis altitude?

	XYZ := (real, real, real).
	XYZ <- (65.360, void, 42.420)!

Good, all signs can always be void, so there's no problem here, but what
you should see is that this tuple business doesn't scale. Go on, imagine
a bunch of signs representing big, complicated 'objects' with hundreds
of properties.

So we need a grammatical way to specify arbitrary composites.

	{ either this, }
	XYZ ::
	  x := real.
	  y := real.
	  z := real.

	{ or this: }
	XYZ :: x, y, z := real.

	Point := XYZ.
	Point <-
		x -> 65.360.
		y -> 42.420.

	{ Equivalent. }
	Point's x = x of the point.

What you see above is just one of the ideas that's being discussed at
the moment.

Feel free to chime in on the ideas!


[1] https://aletheia.icu/~badt/logos/spec/
[2] https://unicode.org/glossary/#code_point
[3] https://fsharpforfunandprofit.com/posts/elevated-world/
Reply to thread Export thread (mbox)