Live data from Hacker News

Just what does “code as data” mean anyway? (2014)

adambard.com

151–160 of 178 posts

Re: Just what does “code as data” mean anyway? (2014)

#151

Earlier quoted context omitted.

I really value C syntax. I'm convinced it's much easier to navigate with the eyes than "oatmeal with fingerclips mixed in" (quoting Larry Wall). And >90% of the time the relevant syntactic unit is on its own line or ranges of lines, and that's really super easy to handle in vim. I don't think there is much to improve by building more complex abstractions on top. If you use vim as a C programmer, you should know the b…

> oatmeal with fingerclips mixed in" (quoting Larry Wall). That exact phrasing only seems to show up in 2 places: this comment, and a comment of yours from about a year ago. So I suspect you're paraphrasing...but my purpose for looking was to find that talk/essay/whatever. Would you happen to have a link?

Here (is the (source)): https://groups.google.com/d/msg/comp.lang.clos/edcyFOBLMeo/M...

Re: Just what does “code as data” mean anyway? (2014)

#152

Earlier quoted context omitted.

> Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code. Is there a single programmer on this planet who thinks about code in terms of letters, words, lines, or paragraphs? Newsflash: it's 2018, not 1960, and code editors are capable of things most lisp "editor modes" can only dream about.

I wish people who downvote my comment would explain what they disagree with. The entire discussion in this subtree centers around paredit (oooh, it can slice and slurp lists!) and vi commands. Have you ever ever seen and experienced an actual modern coding environment? IntelliJ IDEA? Visual Studio? Hell, even Visual Studio Code. The full power of those tools put both vi and paredit to shame when it comes to actually…

I downvoted because your comment sounds argumentative and condescending. So does this one.

Re: Just what does “code as data” mean anyway? (2014)

#153
post #84

Earlier quoted context omitted.

Sure there is. Imagine you had this function: int f(void) { int x = 1; return x * 2; } Then pretend that later you wanted to call f and provide your own value of x for it to transform, but you realise that f doesn't take a parameter, so you go to move the x declaration in f into its parameter list. What you really want to do here is delete the first element of the parameter list, and then move the first expression in…

Tooling is getting better for non-Lisp languages. In C#, with Visual Studio and ReSharper, for example, you could highlight the "int x = 1;" line, and hit your keyboard shortcut for ReSharper:Introduce_Parameter, which would do pretty much exactly what you're saying. Same for turning a chunk of code into a method, etc.

The tooling is there, it's not bad, and it is constantly getting better.

I use Cursive in IntelliJ to do all my Clojure programming. A lot of others also use Emacs but Cursive is an amazing plugin imho. It does the vast majority of things I want from an IDE, like jumping to definitions, some refactorings, switching easily to relevant test files. Paredit took a while to get used to but I immediately miss it when programming anything else.

Re: Just what does “code as data” mean anyway? (2014)

#154
post #84

Earlier quoted context omitted.

Sure there is. Imagine you had this function: int f(void) { int x = 1; return x * 2; } Then pretend that later you wanted to call f and provide your own value of x for it to transform, but you realise that f doesn't take a parameter, so you go to move the x declaration in f into its parameter list. What you really want to do here is delete the first element of the parameter list, and then move the first expression in…

Tooling is getting better for non-Lisp languages. In C#, with Visual Studio and ReSharper, for example, you could highlight the "int x = 1;" line, and hit your keyboard shortcut for ReSharper:Introduce_Parameter, which would do pretty much exactly what you're saying. Same for turning a chunk of code into a method, etc.

[deleted]

Re: Just what does “code as data” mean anyway? (2014)

#155
post #122

Earlier quoted context omitted.

Haskell comes from a family of languages called ML. And ML was known as Lisp without parentheses. So its again Lisp all over again.

I don't know that I've ever seen someone call ML "Lisp without parentheses". Regardless, even with some familial relationship and a few principles in common (like a commitment to functional programming) the two lineages are far more different than they are alike: Lisp has a powerful dynamic core and intricate metaprogramming capabilities, while Haskell builds on a powerful type system and non-strict evaluation. Sayin…

>>I don't know that I've ever seen someone call ML "Lisp without parentheses".

My bad. It's called Lisp with types. From: https://en.wikipedia.org/wiki/ML_(programming_language)

Now. Haskell does look like a impractical scheme. Beyond that, today if you want it, you have typed racket.

For a lot of people you could just go ahead use Racket/Lisp instead of Haskell instead.

Re: Just what does “code as data” mean anyway? (2014)

#156
post #129

Earlier quoted context omitted.

You seem to be suggesting (sum 1 2 3 4 5) and sum(1, 2, 3, 4, 5) are the same because they both return 15. That's just one way of looking at things. And that is true only if, that one is the only way of looking at things. Structurally (sum 1 2 3 4 5) and sum(1 2 3 4 5) are NOT similar. They are not even close, in fact they represent opposite schools of thought. There is a reason we are insisting on everything being l…

task3(task2(task1(work))) can, with the function apply(data, *funs): return reduce(lambda d, f: f(d), [data] + funs) be rewritten as apply(work, task1, task2, task3) Its possible in exactly the same set of cases, namely those where each task takes a single argument/is provided as a partial. I expect that `->` is implemented in clojure in much the same way (and [1] implies that, modulo some scaffolding and error check…

Sorry but again, using a workaround doesn't mean they are the same. When I mean same, I mean structurally.

Re: Just what does “code as data” mean anyway? (2014)

#157
post #129

Earlier quoted context omitted.

You seem to be suggesting (sum 1 2 3 4 5) and sum(1, 2, 3, 4, 5) are the same because they both return 15. That's just one way of looking at things. And that is true only if, that one is the only way of looking at things. Structurally (sum 1 2 3 4 5) and sum(1 2 3 4 5) are NOT similar. They are not even close, in fact they represent opposite schools of thought. There is a reason we are insisting on everything being l…

sum(1, 2, 3) and (sum 1 2 3) are just different read/print notations that can map to exactly the same data structure and therefore "do" everything the same way. The --> macro invocation would just look like -->(work, task1, task2, task3). There are good reasons for considering f(x, y) to be a bad notation compared to (f x y); but this isn't one of them.

That was just an example. In general, those representations are not the same. Structurally.

Re: Just what does “code as data” mean anyway? (2014)

#158
M-LISP: a representation-independent dialect of LISP with reduction semantics

In this paper we introduce M-LISP, a dialect of LISP designed with an eye toward reconciling LISP's metalinguistic power with the structural style of operational semantics advocated by Plotkin [28]. We begin by reviewing the original definition of LISP [20] in an attempt to clarify the source of its metalinguistic power. We find that it arises from a problematic clause in this definition. We then define the abstract syntax and operational semantics of M-LISP, essentially a hybrid of M-expression LISP and Scheme. Next, we tie the operational semantics to the corresponding equational logic. As usual, provable equality in the logic implies operational equality. Having established this framework we then extend M-LISP with the metalinguistic eval and reify operators (the latter is a nonstrict operator that converts its argument to its metalanguage representation). These operators encapsulate the metalinguistic representation conversions that occur globally in S-expression LISP. We show that the naive versions of these operators render LISP's equational logic inconsistent. On the positive side, we show that a naturally restricted form of the eval operator is confluent and therefore a conservative extension of M-LISP. Unfortunately, we must weaken the logic considerably to obtain a consistent theory of reification.

Re: Just what does “code as data” mean anyway? (2014)

#159
post #156

Earlier quoted context omitted.

task3(task2(task1(work))) can, with the function apply(data, *funs): return reduce(lambda d, f: f(d), [data] + funs) be rewritten as apply(work, task1, task2, task3) Its possible in exactly the same set of cases, namely those where each task takes a single argument/is provided as a partial. I expect that `->` is implemented in clojure in much the same way (and [1] implies that, modulo some scaffolding and error check…

Sorry but again, using a workaround doesn't mean they are the same. When I mean same, I mean structurally.

But they are structurally the same that's my point. I can implement -> practically directly. There is no structural difference that you've demonstrated.

That is not idiomatic and common in Python didn't mean that there is some structural difference. Basically the transformations you're describing are doable with regex, which is the opposite of powerful.

What you've done is take code is data, which is powerful, and confuse that with "supports varags", which is less powerful, and claim that the second is unique and powerful when it is not unique, and not uniquely powerful.

Re: Just what does “code as data” mean anyway? (2014)

#160

I think there’s a much simpler example of how code is data: (hello world) That’s a list containing two symbols. So it’s data. However, if I evaluate that list, it will call the function “hello” with the argument “world”. So it’s also code. Incidentally, lists and function calls are identical in lisp, hence code is data. I think the article just complicates it by introducing macros.

'(hello world) is a list (hello world) is a function call

Typically when writing about lisp code, it is also correct to talk about how "read" sees the expression, to avoid some confusion about what happens after "eval". That's how I interpret the parent comment when it says that (hello world) is a list of two elements.
Post reply on HN