Can your programming language do this?

http://arohner.blogspot.com/2009/07/can-your-programming-language-do-this.html

by arohner • 17 years ago

50 61 17 years ago

arohner.blogspot.com

icey• 17 years ago

IIRC this will also work with PLT Scheme and (I think) Common Lisp (I can't remember if you can use unicode names in CL).

arb2• 17 years ago

You can. For instance, SBCL introduced support for it around version 0.8 or so (years ago).

mitko• 17 years ago

Yes, it can. All programing languages are equivalent in power, as you can write interpreter of language A in language B for, I think, any two programming languages A and B.

However, some languages will achieve some things much easier. Your language apparently makes it pretty easy to create new functions such as sum or product.

gaius• 17 years ago

Nah, his point is that he can use the standard mathematical symbols directly because his language is Unicode-native. That's hard to retrofit.

scott_s2• 17 years ago

Start with the section "The Blub Paradox": http://www.paulgraham.com/avg.html

bogdank• 17 years ago

APL was capable of doing something similar. It would be nice to have keyboards with extended set of characters.

buugs• 17 years ago

I don't know if it will be of much use but take a look at http://www.jsoftware.com/ it is similar to apl in style

gchpaco2• 17 years ago

J took one of APL's chief positives, the only thing that made it possible to look at absurdly dense APL code and make sense of it, and destroyed it. APL has a "one character == one primitive" relation, except for user symbols which all have to be letters. So no matter what jumble of crap you had, you could tokenize it easily starting from anywhere. J has variable length characters.

silentbicycle3• 17 years ago

As is k. (http://kx.com/)

tokipin• 17 years ago

for the sake of language geekdom, it would be done in J something like this:

  - +/ p * ^. p

where p is the array. you can even remove the duplication of the array with a so-called hook:

  - +/ (* ^.) p

slackenerny2• 17 years ago

keyboards

http://pckeyboards.stores.yahoo.net/adcolkey.html

Sharlin• 17 years ago

Well, I certainly prefer it spelled "sum" -- trivial to understand and viewable with any font.

In idiomatic Python, with only basic language features needed:

-sum(p(x) * log(p(x)) for x in l)

brent• 17 years ago

In matlab: -sum(p(x).*log(p(x)))

Both look much cleaner imo.

DanielStraight• 17 years ago

Yes. Why should something which is NOT written in prefix notation in math be written in prefix notation in code? What is so impressive about that? All of my programming languages (who has just one?) can define nice looking functions. None of them use obscure prefix notation, and I think that's a good thing.

dreish3• 17 years ago

I think the point was that author was able to create a syntax for summation that had approximately the same shape as the math notation.

I don't think I would argue that this is a very good example of macros (and yes, I wrote that before reading pg's comment ;), but solutions people have posted with other languages all have foreign symbols in them -- syntax for passing around blocks, or language-defined looping or list comprehension syntax, not ones they have chosen to suit their own needs. In this case, that's a virtue; you learn the language's syntax, and then you know how to recognize summation within any program in that language regardless of who wrote it, but in cases where the problem is more complicated and the native syntax for what you need to do more awkward, you really do want to create your own syntax.

Arguably that's a danger inherent in Lisp: it gives more opportunities to create needless new syntax, not just the kind of syntax that makes a program clearer and simpler.

If you wanted to extend destructuring in Python (that is, (a, b) = (1, 2)) to cover dictionaries, how would you do it? In a Lisp, it's done with macros. The core language usually doesn't start out with any destructuring at all. In Python, you can beg Guido and wait, or fork the project -- neither option is practical.

tome3• 17 years ago

That facility's already there. Any object is unpacked using its __iter__:

   >>> d = { 'key1': 'val1', 'key2': 'val2' }
   >>> (x,y) = d
   >>> (x,y)
   ('key2', 'key1')
   >>> (x,y) = d.items()
   >>> (x,y)
   (('key2', 'val2'), ('key1', 'val1'))
   >>> (x,y) = d.values()
   >>> (x,y)
   ('val2', 'val1')

ulvund• 17 years ago

  entropy <- function(x)  -sum(p(x)*log(p(x)))

tedunangst• 17 years ago

"Having a language that lets you declare constructs that look very similar to their mathematical definition is a huge win for readability."

I'd agree, except every mathematical definition I've seen used infix notation. Minus a function for summing a series, the C version at least keeps the symbols in the same order. Anyone with even a passing familiarity of C can read this and recognize it as the same thing.

  double entropy(int x) {
    double e = 0.0;
    for (int i = 0; i < x; i++) e += p(i) * log(p(i));
    return -e;
  }

judofyr• 17 years ago

Works nicely in Ruby 1.9:

  #!/usr/bin/ruby -Ku
  # encoding: utf-8
  module Enumerable
    def sum
      inject { |acc, val| acc + val }
    end

    def Σ(&blk)
      map(&blk).sum
    end

    def entropy(&prob)
      - Σ { |i| prob[i] * Math.log(prob[i]) }
    end
  end

EDIT: And in 1.8 if you pass -Ku.

jrockway3• 17 years ago

This also works fine in Perl, Common Lisp, and Haskell... and probably every other programming language that was designed after 1970.

pg2• 17 years ago

Yes, and in fewer tokens:

    (def entropy (x) 
      (- (sum [* (p _) (log:p _)] x)))

I like macros, but I wouldn't use them in this case. Summing is close enough to mapping that the form above is easy for any Lisp programmer to understand.

I'd also argue that code size is a more meaningful measure of readability than familiarity. There's nothing intrinsically right about sigma notation. Some people are just more used to it. But since whatever notation you put in a language will eventually become familiar to its users, you should factor out familiarity when making design decisions, or at most use it to break ties. The notation above is honestly more readable to me, because it's what I'm used to.

arohner• 17 years ago

I'm honored you read my post and replied to it.

> I'd also argue that code size is a more meaningful measure of readability than familiarity ... but since whatever notation you put in a language will eventually become familiar to its users, you should factor out familiarity when making design decisions

An exaggerated, uncharitable interpretation of what you said would be "users will figure out the notation, regardless of how hard it is, so make them jump through hoops so you can get a shorter notation". How do you distinguish between shorter notation that is a net win, and shorter notation that looks like perl?

My goal in using the macro was to reduce noise. Without the macro, the equivalent clojure would look like

    (defn entropy [x]
        (- (Σ #(* (p %) (log (p %)) x))

To me, the original version is easier to read because it lacks the #, % characters. Given that every call to sum would likely use an anonymous function (and therefore use #, %), it seemed worthwhile. Maybe that's an argument against clojure, but the arc version is almost as noisy, IMO.

jrockway3• 17 years ago

If you can write something as a function, that's always a better option than making it a macro. It's clear to any clojure programmer what your entropy function does, just like it's clear to any Perl programmer what all that "line noise" is. (Arguably, there isn't much line noise in Perl, only in regular expressions, which every other language has stolen Perl's implementation of. If you want real line noise regexps, try Emacs Lisp without "rx".)

arb2• 17 years ago

Perhaps it's the function shorthand syntax that resembles Perl. This is closer to your macro's surface syntax:

    (Σ (fn [i] (* (p i) (log (p i)))) x)

The tradeoff with your macro version is that when you want to leverage Σ as a first-class function (say, with comp or partial), you will end up with #() or (fn..) in the calling code. You can't escape it -- it's a natural way to write functional Lisp code.

It's no less readable than the rest of Clojure's API. You can reasonably expect a Clojure user to understand functions as arguments.

pg2• 17 years ago

I think we should distinguish between notations that allow users to write incomprehensibly terse code and those that force them to. Only the latter are a problem, unless you're taking the protect-users-from-themselves approach to language design.

It's an interesting question whether there are any existing language constructs that force one to write unreadable code. I ended

http://www.paulgraham.com/power.html

by asking for examples, and I don't think I ever got any.

jonshea• 17 years ago

While I see where you’re coming from as an application programming, people who do primarily scientific programming ∑ is much more intuitive than 'sum'. When I was doing scientific programming I would have killed for unicode source support. There isn’t always an obvious way to transform a math variable into ASCII. Consider,β for example, which can mean “the ratio of the thermal energy density to the magnetic energy density of a plasma”. In conversation people generally pronounce that as just “beta”. You could spell “beta” out in code, of course, but what if you have a β sub σ and a β sub s to juggle? And what if you have a prime or a superscript on those variables too?

The hairier equations can juggle several similar variables and carry on for several lines of code. It isn’t always obvious how to break them apart into smaller functions like you would in a normal application. Using income literals instead of spelling variables out can save a lot of space. More importantly, it makes the code look more like the source material, which makes mistakes much easier to spot.

jf• 17 years ago

This reminds me of the Fortress programming language:

http://research.sun.com/projects/plrg/Publications/fortress....

(Image from the part of the above PDF that I was thinking of: http://skitch.com/joelf/bs99c/sun-research-fortress)

TweedHeads• 17 years ago

Javascript can do it all:

  function entropy(x){ return sum(p(x)*log(p(x))); }

amix• 17 years ago

I am looking forward for Fortress 1), which takes these ideas to the extreme (basically, the whole language is unicoded and the syntax is mathematical). Fortress also features some very innovative features such as implicit parallelism for a imperative language and transactions. One of the creators of Fortress is Guy Steele (one of the guys behind Scheme, Lisp and Java).

1) http://projectfortress.sun.com/Projects/Community

keefe• 17 years ago

I don't think the readability of implementations is all that important. Java is widely regarded as having poor syntax, but any client of this type of a method (assuming it is in a static utility class) will do something like double myEntropy = InformationTheory.entropy(myseries); The details of a method like that just aren't all that interesting, it's 10 lines or 200 (likely the latter as there seems to be an optimized version for doing anything). I like to abstract away mathematically complex(ish) things like this and leave syntax like I stated above in my code, so that my code tells a story that is easy to read about how data is being manipulated and really focus on the high level semantics of what is going on. Maybe I am influenced from having done clerical work in HS and typing fast enough that a few lines doesn't matter, but sometimes I prefer longer code, with more interfaces and more abstraction and more standardization to concise and elegant but more obscure approaches.

trezor3• 17 years ago

C#:

    Func<List<double>, double> entropy = (X) =>
    {
        double e = 0;
        X.ForEach((p) => e += p * Math.Log(p));
        return -e;
    };

Compiler gets negative points for not being willing to infer the type-definition of the function-variable though. I guess that is stuff you have to live with in statically typed languages ;)

Edit: Just checked. C# allows unicode characters like Σ for functions and variables, although I would never use it myself.

snprbob86• 17 years ago

Not sure why you are using lambda syntax instead of defining a method shrug, but anyway I don't think the type inference shortcoming is inherent to static typing.

See this similar post regarding type inference on fields: http://blogs.msdn.com/ericlippert/archive/2009/01/26/why-no-...

I'm sure there is an equally reasonable explanation of costs and implications for your example. Eric Lippert would probably be happy to share it with you, why not ask him? :-)

scott_s2• 17 years ago

You're right, statically typed languages can use type inferencing; both Haskell and Ocaml do.

trezor3• 17 years ago

I'm sure there is an equally reasonable explanation of costs and implications for your example.

There sure is. Had I defined a method (like you suggested), and just gone ahead and made my function variable point to that, the compiler would have enough information to infer types. In that case I would get away with the following:

  var someFunction = (X) => entropy(X);

Just felt like contributing somethings which isn't on the HN daily list of languages, that's all :)

profquail• 17 years ago

Or you could just do this:

double entropy = -1.0d * mydata.Select(x => x * Math.Log10(x)).Sum();

Where 'mydata' is of type IEnumerable<double>.

trezor3• 17 years ago

I knew there was a simple and concise syntax I was missing. Writing code after midnight is definitely a nono :)

jrockway3• 17 years ago

Yes, my programming language can do that.

Tichy2• 17 years ago

But how do you type the Σ? Don't do stuff like that... In one project I had to use a templating language that used "<<" as a single character (I still can't type it) instead of <% %> like all the other languages in the world. I ended up using copy and paste for that character whenever I had to edit the templates. Needless to say I enjoyed that project tremendously.

Really don't do that - try to stick to ASCII in the source code please.

gruseom3• 17 years ago

But how do you type the Σ?

You simply define a keyboard shortcut.

For very common primitives, a special character can work nicely. We use λ in our Common Lisp code instead of typing lambda. Actually, our λ is a macro that does a couple of things besides expanding into lambda; if it were just the latter we probably wouldn't have gone there. Once we did, though, I was surprised at the improvement in readability.

Tichy2• 17 years ago

Interesting. But I hope you put something in the comments of your code on how to create that keyboard shortcut and the unicode for λ.

jasonkester2• 17 years ago

Ugh. If anybody ever has to maintain your code, they'll copy/paste the symbol like Tichy described while cursing your name. Personally, I'd copy/paste it into the global find/replace dialog the first time I came across it.

I mean, sure, if it was my job to deal with your unicode code every day from here on out, I'd bother to learn how to map screwy symbols to keyboard shortcuts. But really, why would you do this to your code in the first place? It certainly doesn't make things more readable. Exactly the opposite.

slava_pestov• 17 years ago

Here's a point-free version in Factor. It looks a bit different from the original formula but once you get used to it its very quick to read; I prefer it to the Lisp code since there are fewer parentheses to track:

    : entropy ( n -- e ) [1,b] [ p dup log * ] sigma neg ;

Note that [1,b] is a word which makes a numeric range from an integer on the stack, and [ ... ] is a function object (quotation).

gregwebs• 17 years ago

haskell list comprehension

entropy x = - sum [p i * (log . p) i | i <- [1..x]]

hs• 17 years ago

yes, lisp can make certain math simpler

consider bounds on a: 0 < a < 1; it's (and (< 0 a 1) (foo)) ... should be easy in any language

how about 0 < a < b < 1 ? it's (and (< 0 a b 1) (bar)) ... a little ugly in other languages

0 < a < b < ... < z < 1 ? i won't program that in other languages :p

Can your programming language do this?

Related Stories