Uniform Structured Syntax, Metaprogramming and Run-Time Compilation

Post by [deleted] » Mon, Jun 17, 2019, 4:49 PM UTC

comma_at wrote: post #31

firethief wrote: post #29

Earlier quoted context omitted.

A lot of people have experience with simple VMs. There's nothing super unique about this problem that requires every claim about it to be accompanied by a proof by construction.

Either you missed the context or are pulling a straw man. Building a simple VM is not unique, but can you build one that will be competitive with the other's in a reasonable timeframe?

Post by barrkel » Mon, Jun 17, 2019, 8:18 PM UTC

comma_at wrote: post #25

barrkel wrote: post #9

This is talking about evaluating dynamic expressions over (semi-?)-structured row-oriented data, for the purpose of filtering. It contrasts a tree interpreter in C++ with a JITted dynamically generated Lisp expression, with some hand-waving away of what the equivalent JIT in C++ would be, seemingly dismissing it as taking too long (is that what "unpause cosmic time" alludes to? I'm not sure). The tree interpreter is…

Unless you provide one of - a simple VM implementation - code using a JIT framework - using Apache Impala on this particular dataset which performs on par and didn't take astonishingly long to write then these are just vague claims and hypotheses.

Post by quelltext » Tue, Jun 18, 2019, 11:07 AM UTC

comma_at wrote: post #24

quelltext wrote: post #16

Earlier quoted context omitted.

You still have the problem that the `my-dsl-macro` is a black box. That macro can do anything it wants to the sub-AST. The problem is not about hygiene re: variables but about the meaning of symbols. A function application within it that doesn't obviously have anything to do with the DSL is also subject to the macro's will to have its meaning changed. This can make composition difficult. Who guarantees that if you co…

> Who guarantees that if you combine `my-dsl-1-macro` with `my-dsl-2-macro` or simply with general purpose code, that they don't interfere in odd ways? Nobody does. But that's where the power lies. You can't have unrestricted power with restricted features. Lisp gives you unrestricted power. It's up to you to use it correctly, for w/e definition of correct your context makes sense.

Post by m00natic » Tue, Jun 18, 2019, 12:18 PM UTC

Veedrac wrote: post #5

I'm not sure if I'm missing something, or if this is meant to be allegorical for some other, more difficult problem, but the argument here seems very strange. For sure, C++'s string handling is an awful sight, but the jump to DSLs seems unmotivated. This issue can be handled with simple, traditional helper functions. select(recordS5, [](cxr, subcode, commercial_name, date_disc) { return cxr.like("YY|XX") && ...etc; }…

Post by m00natic » Tue, Jun 18, 2019, 2:31 PM UTC

Veedrac wrote: post #39

m00natic wrote: post #38

Earlier quoted context omitted.

It's allegorical in the sense that this is general Lisp technique useful not just in this case. The DSL is targeted at (non programmer) end users and supposed to be fired through a REPL. Wouldn't want to make them write C++ with lambdas, semi-columns and whatever syntax traps of the latest standard.

That doesn't support the post's argument, that it's not about aesthetics, but about qualitatively simpler solutions. > Often times I hear the claim that (programming language) syntax doesn't matter or if it does, it's only to provide some subjective readability aesthetics. It's somewhat surprising to me how large majority of supposedly rational people like programmers/computer scientists would throw out objectivity w…