Gustavo Lacerda

i am genuinely curious why you think this is nicer than mapi (fn (v,i) => [code]) list?

From:

because I don't understand the ML solution.

is "fn" like "lambda" and "=>" like the "." following a lambda?

Your one line of code above doesn't enumerate.

From:

yep, fn is lambda and '=>' is '.'.

it does enumerate. it applies the provided function (which takes the index as an argument) to every element of the list, and returns a list of the results. "appi" can be used if you just want to apply some effectful computation to every element, like printing it.

From:

bhudson.livejournal.com

The writeup looked frightening. "Vector.mapi, comma, you dumbass" would have worked better than starting from first principles and then pointing out that actually you don't need to implement quite everything.

You can abbreviate the writeup even further if you're single-national Canadian.

From:

yeah, well, maybe if some verbose jerk hadn't gone and stolen the opportunity. :P

but yeah i dunno, posting the actual implementation seems pedagogically more necessary in the ML example since a "map" call is totally bizarre-looking to someone used to seeing a loop structure.

From:

bhudson.livejournal.com

But if you're trying to teach someone how to write mapi (fn (x, i) => printf I'" => "S $ i x) thelist, and you're worried they won't understand that line of code, why expect they'll get any illumination out of the implementation of mapi?

This is a problem I've frequently had with CMU SML people. I'm used to a world that believes in abstraction. This method of giving the detailed implementation first is the very antithesis of abstraction.

From:

yeah, you make a good point. i think in this case my instincts were just wrong. i'm going to have to think about why i had them.

From:

For me it was just truth in advertising: SML doesn't come with a List.mapi. But also, there's the point to be made that in a higher-order language, you're not tied to whatever looping constructs "come with" the language -- you can just roll your own, and people frequently do.

From:

bhudson.livejournal.com

I suspect that's part of the difference between people who care about languages qua languages, rather than people who care about languages as problem-solving tools. Looking at it as a language, I *hate* python and its utter lack of static typechecking. As a tool, it's pretty decent - it's got a huge user community who have hit the same problems I hit, and have developed a rich set of libraries. SML isn't (sadly) even an option right now: I'm writing plugins for an application software, and for some odd reason there just isn't an SDK in SML.

From:

my apologies for being civil? :P

From:

For the record, i'm usually happy to take questions if you're happy to ask them :P

Here's a very short solution in another language you probably don't know:

  zipWith (\ i v -> ... code ...) [1..] list

Maybe Haskell is inherently more readable, though? :P This one makes creative use of laziness!

From:

I was intimidated. And I can't afford more than 2 minutes on this...

From:

http://gustavolacerda.livejournal.com/1016649.html?thread=3869001#t3869001

From:

IMHO

mapi (fn (i, el) => ... code(i, el) ...) list

is less elegant than

for i, v in enumerate(list):
  code(i, v)

because

* the Python fewer tokens
* in the ML, what the heck is "..." anyway?
* in the ML, one explicitly writes the lambda. One of the reasons Paul Graham invented Arc is because "lambda(x)" appears too often in Lisp.

Edited Date: 2010-04-29 05:20 am (UTC)

From:

The "..." isn't ML -- just metasyntax for "some junk goes here".

From:

Regarding the lambda, in ML's defense, it is at least shorter and more distinctive than LISP's. Haskell takes it to the exteme, with "\ x ->" instead of "lambda (x)". Macros for inventing new binding constructs might be nice, I suppose, but there's a trade off: if everyone invents their own syntax, nobody can read anybody else's code anymore, or even be able to tell which variables are bound.

From: