[deleted]
Uniform Structured Syntax, Metaprogramming and Run-Time Compilation
11–20 of 45 posts
Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation
#12This 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…
TFA seems like a challenge to C++ fans, not to sketch out a better solution, but to actually run a better solution against the same data.
Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation
#13Earlier quoted context omitted.
Oh, wow, this is excellent, and fixes it! I never knew about this option. Thank you, sincerely, TeMPOral!
You're welcome. It's a life-saver, in cases like this, or when a mobile site disables the ability to pinch-zoom.
Pinch zooming can also be force-enabled for all sites in the browser's accessibility settings.
Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation
#14I'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; }…
A typical Lisp program of any size is an implementation of a library or language which reflects the natural way your domain would typically be expressed, which is then used to describe your solution.
I was so steeped in this model that I was surprised when I first heard the (relatively recent) expression “DSL”. I mean that’s one of the main values from abstraction.
Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation
#15This is very impressive in only the way that lisp can be. But part of why it works is because SQL is a well defined interface. There was a comment on ltu a good while back: ------------ "I would say that a system that allowed other metathings to be done in the ordinary course of programming (like changing what inheritance means, or what is an instance) is a bad design. (I believe that systems should allow these thing…
I think more analogous to the examples Kay was giving would be for a single program to quietly change the rules for function application, or to quietly change the behavior of CLOS.
I think of an embedded DSL, based on a macro like it is here, as a bit different than that, because it's not doing anything quietly -- it applies only to the parenthesized extent of the code that begins with your macro name:
(my-dsl-macro my dsl fills the rest of the parentheses)
Ideally, your editor will also color the macro names differently, especially for readers who don't know what's a macro or a function. (Rust adds an exclamation mark to the macro name for a use, which is a good idea when you don't already know what's macros, but maybe a bit annoying to have all those exclamation marks when you do know that, say, `println` is a macro.) But even if you don't know the name is a macro, you'll be clued in if the text within it doesn't look like your top-level language, which it often doesn't (e.g., SQL in s-expressions doesn't look like base CL).
A key is to use DSLs judiciously -- for improved readability (for your base language programmer, or domain experts), maintainability, and/or performance. Maybe not for, say, a convenience for the sake of minor code terseness improvement only.
Of course, SQL is a whopper of a language, and perhaps overkill if you invented it as a DSL for this particular application. (More suspicious would be to invent your own relational query language that seems gratuitously different than SQL, when SQL already existed.)
As for changes more like I think Kay was talking about, in the Racket (Lisp family) universe, outside of a macro, normally you wouldn't do that, but when you have a good reason -- say, you want to prototype a lazy language, or implement a specialized language for a GPU programming backend, or a DSL for your domain experts -- you can. In that case, you'd have a `#lang` line at the very top of the file that tells you what different language this is, instead of `#lang racket`. You might make that produce modules that can interoperate with modules of other `#lang`s, but you're not doing anything sneaky that breaks the language of those other modules.
Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation
#16This is very impressive in only the way that lisp can be. But part of why it works is because SQL is a well defined interface. There was a comment on ltu a good while back: ------------ "I would say that a system that allowed other metathings to be done in the ordinary course of programming (like changing what inheritance means, or what is an instance) is a bad design. (I believe that systems should allow these thing…
I think more analogous to the examples Kay was giving would be for a single program to quietly change the rules for function application, or to quietly change the behavior of CLOS. I think of an embedded DSL, based on a macro like it is here, as a bit different than that, because it's not doing anything quietly -- it applies only to the parenthesized extent of the code that begins with your macro name: (my-dsl-macro…
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 combine `my-dsl-1-macro` with `my-dsl-2-macro` or simply with general purpose code, that they don't interfere in odd ways?
Granted, this is not a big concern for a well-designed and widely used macro. However, the bottom line is that the inherent freedom of the abstraction allows for issues to arise whose debugging require a deep understanding of the involved macros and their implementations.
You don't really have the same problem if there is only procedural abstraction. The boundaries are clearer there. Even if you do something like the Interpreter Pattern or Haskell style AST-constructing EDSLs, you have guarantees that whatever AST is constructed cannot inspect whatever non-DSL code you combined with it.
Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation
#17I'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; }…
[deleted]
Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation
#18If I remember correctly, Postgres was initially developed in Lisp, but then rewritten. Was that a mistake, or evidence against the thesis of this article?
Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation
#19This is very impressive in only the way that lisp can be. But part of why it works is because SQL is a well defined interface. There was a comment on ltu a good while back: ------------ "I would say that a system that allowed other metathings to be done in the ordinary course of programming (like changing what inheritance means, or what is an instance) is a bad design. (I believe that systems should allow these thing…
I think more analogous to the examples Kay was giving would be for a single program to quietly change the rules for function application, or to quietly change the behavior of CLOS. I think of an embedded DSL, based on a macro like it is here, as a bit different than that, because it's not doing anything quietly -- it applies only to the parenthesized extent of the code that begins with your macro name: (my-dsl-macro…
I've never wrote commonlisp for work, but what I've read from people doing so is that they're not fools. All those I've seen had a clear notion of when and how much to abuse lisp power. Ugly is ugly and rare are seasoned lispers that are still confused on this.
Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation
#20If I remember correctly, Postgres was initially developed in Lisp, but then rewritten. Was that a mistake, or evidence against the thesis of this article?
Not really, the original Postgres was developed in a mix of 17000 lines of Lisp and 63000 lines of C. This was difficult to develop/debug at that time. Probably still would be.
It had a 'gigantic' memory footprint of 4 MB - the all-in-C version only used 1 MB. The Lisp version was also slower and they didn't use features like GC...