3 ms·

Because aif works with any expression, not just print. Granted, in a functional language like JS, one could say: ifNotNull(foo.getBar().getName(), function

by andreyf 17y ago

Because aif works with any expression, not just print. Granted, in a functional language like JS, one could say: ifNotNull(foo.getBar().getName(), function (it) { print it; }); but "function (it)" and all of the "().{}" are still blub. As PG points out on the arclanguage forums [1], an even simpler way of putting it is: (only.print foo!bar!name) Which, without the Arc-specific syntax sugar, is: ((only print) ((foo 'bar) 'name)) So "only" is a modifier that makes a verb (function) happen only if its argument is truthy (think Python decorators). Note to PG: the dot operator is undocumented, and f.g.h.3 does not at all what I expect - looks like it does (f g h 3), whereas I expected (f (g (h 3))), in the spirit of Python decorators. 1. http://arclanguage.org/item?id=9350 http://arclanguage.org/item?id=9350

axod 17y ago
In js, if printIt is a function already defined, you don't need the function(it){} ifNotNull(foo.getBar().getName(), printIt); Granted, in java passing functions around is more of a pain.
- klipt 17y ago
  Yep, a lot of the features mentioned in the presentation are possible with just first class functions, although the syntax will be messier (but arguably more consistent). The strength and danger of macros is in allowing you to create new syntax, skipping all the extra blub that made your code conform (consistently) to the original parser. What I'd like to know though is how much humans depend on that blub. It's one thing to write your own macros and use them consistently, or even for a group of people to come up with macros and use them consistently. But if people work independently, what happens when you read someone else's code and find they've come up with macros to do the same things as yours do, but with different names and different usage conventions? Wouldn't that be a bit like having every scientist invent their own jargon? Either humans can learn to translate that kind of thing on the fly, or they can't, and lisp with heavy macro usage will only ever be useful as a solo (or small group) language.
  - andreyf 17y ago
    Wouldn't that be a bit like having every scientist invent their own jargon? I don't know about "all scientists", but mathematicians do precisely this all the time! Each paper and each textbook begins by defining what symbols mean what, and which terms are used how. But a textbook is about as big a consistent block of terminology as you'll be able to find. In a grander sense, terms are constantly re-purposed and evolving over time [1]. Something as simple as "⊂" will mean "subset" in one book, and "strict subset" in another. In my experience, the older the book, the more divergent it'll be from current usage. This suggests that the language of mathematics evolves over time, precisely because every practitioner can change the language and push for her own terminology. There is no "Mathematics corporation" which creates languages people would be forced to choose from - no mathematician, no matter how great, would suggest that he would know what the "eternally right way" of expressing mathematics is. This is especially apparent in more exploratory parts, where definitions start being named after their authors. I, personally, look forward to a time when I get to choose between a Norvig-garbage-collection and Graham-garbage-collection for each object in my code. We're in this ridiculous stage of software engineering, where, if you're using Java, you have to do garbage collection The Java Way (you get to set a couple of settings, but that's it). No mathematician would ever be forced to make the decisions that Sun's engineers were forced to make when designing Java, because nobody could make those decisions correctly - how programs must interact with the call stack, the mechanics of method invocation, etc. 1. "Compactification" comes to mind as an example: http://en.wikipedia.org/wiki/Compactification_%28mathematics%29 http://en.wikipedia.org/wiki/Compactification_%28mathematics...
  - gruseom 17y ago
    what happens when you read someone else's code and find they've come up with macros to do the same things as yours do, but with different names and different usage conventions? Wouldn't that be a bit like having every scientist invent their own jargon? You can replace the word "macros" with "functions" and your point would be the same. Consistency in naming and usage is part of good programming, but the point is orthogonal to macros. Edit: actually, it's not orthogonal: macros make it easier to be consistent because they let you write less code, so there's less code to contradict itself.
- andreyf 17y ago
  For the toy example, sure. But as soon as the example gets at all more complicated, you'll need to throw the function(it){} back in. Also, it's worthwhile to remember that aif does a bit more - it's semantically the equivalent of cond, which sometimes eliminates a ton of if/else blub.
  - latortuga 17y ago
    https://developer.mozilla.org/en/New_in_JavaScript_1.8#Expression_closures https://developer.mozilla.org/en/New_in_JavaScript_1.8#Expre... New in 1.8 you can omit the return and curly braces. So at least a little improvement!
pg 17y ago
(def only (f) (fn args (if (car args) (apply f args)))) The . and ! operators got redefined so that x.y.z is ((x y) z) instead of (x y z). I think I posted the source on arclanguage.org.
- CatDancer 17y ago
  http://arclanguage.org/item?id=9219 http://arclanguage.org/item?id=9219

by andreyf 17y ago

axod 17y ago

In js, if printIt is a function already defined, you don't need the function(it){} ifNotNull(foo.getBar().getName(), printIt); Granted, in java passing functions around is more of a pain.

klipt 17y ago
Yep, a lot of the features mentioned in the presentation are possible with just first class functions, although the syntax will be messier (but arguably more consistent). The strength and danger of macros is in allowing you to create new syntax, skipping all the extra blub that made your code conform (consistently) to the original parser. What I'd like to know though is how much humans depend on that blub. It's one thing to write your own macros and use them consistently, or even for a group of people to come up with macros and use them consistently. But if people work independently, what happens when you read someone else's code and find they've come up with macros to do the same things as yours do, but with different names and different usage conventions? Wouldn't that be a bit like having every scientist invent their own jargon? Either humans can learn to translate that kind of thing on the fly, or they can't, and lisp with heavy macro usage will only ever be useful as a solo (or small group) language.
- andreyf 17y ago
  Wouldn't that be a bit like having every scientist invent their own jargon? I don't know about "all scientists", but mathematicians do precisely this all the time! Each paper and each textbook begins by defining what symbols mean what, and which terms are used how. But a textbook is about as big a consistent block of terminology as you'll be able to find. In a grander sense, terms are constantly re-purposed and evolving over time [1]. Something as simple as "⊂" will mean "subset" in one book, and "strict subset" in another. In my experience, the older the book, the more divergent it'll be from current usage. This suggests that the language of mathematics evolves over time, precisely because every practitioner can change the language and push for her own terminology. There is no "Mathematics corporation" which creates languages people would be forced to choose from - no mathematician, no matter how great, would suggest that he would know what the "eternally right way" of expressing mathematics is. This is especially apparent in more exploratory parts, where definitions start being named after their authors. I, personally, look forward to a time when I get to choose between a Norvig-garbage-collection and Graham-garbage-collection for each object in my code. We're in this ridiculous stage of software engineering, where, if you're using Java, you have to do garbage collection The Java Way (you get to set a couple of settings, but that's it). No mathematician would ever be forced to make the decisions that Sun's engineers were forced to make when designing Java, because nobody could make those decisions correctly - how programs must interact with the call stack, the mechanics of method invocation, etc. 1. "Compactification" comes to mind as an example: http://en.wikipedia.org/wiki/Compactification_%28mathematics%29 http://en.wikipedia.org/wiki/Compactification_%28mathematics...
- gruseom 17y ago
  what happens when you read someone else's code and find they've come up with macros to do the same things as yours do, but with different names and different usage conventions? Wouldn't that be a bit like having every scientist invent their own jargon? You can replace the word "macros" with "functions" and your point would be the same. Consistency in naming and usage is part of good programming, but the point is orthogonal to macros. Edit: actually, it's not orthogonal: macros make it easier to be consistent because they let you write less code, so there's less code to contradict itself.
andreyf 17y ago
For the toy example, sure. But as soon as the example gets at all more complicated, you'll need to throw the function(it){} back in. Also, it's worthwhile to remember that aif does a bit more - it's semantically the equivalent of cond, which sometimes eliminates a ton of if/else blub.
- latortuga 17y ago
  https://developer.mozilla.org/en/New_in_JavaScript_1.8#Expression_closures https://developer.mozilla.org/en/New_in_JavaScript_1.8#Expre... New in 1.8 you can omit the return and curly braces. So at least a little improvement!

pg 17y ago

(def only (f) (fn args (if (car args) (apply f args)))) The . and ! operators got redefined so that x.y.z is ((x y) z) instead of (x y z). I think I posted the source on arclanguage.org.

CatDancer 17y ago
http://arclanguage.org/item?id=9219 http://arclanguage.org/item?id=9219