Lambda the Ultimate

...since it's just a slightly skewed version of Java with some different design decisions. :-)

I got some gift certificates which allowed me to do some impulse shopping today at the bookstore. Stumbled upon CTM and purchased it. Dang, we're not even a day into the new year, and my agenda has already changed. So much for New Year's resolutions.

I do plan to get back to Alice RSN, but I guess I'll be buried in CTM for a whilst. Then again, I played with Oz a couple of years back, so I don't think it qualifies as a new Language of the Year for my purposes.

Joy?

The real Joy of Joy is it's algebraic simplicity. There is a clear algebra ON Joy. You can algebraically manipulate and rewrite Joy programs. This is an incredible notion deserving far greater attention.

http://www.latrobe.edu.au/philosophy/phimvt/joy/j07rrs.html

here and check the LtU archive for more.

You can algebraically manipulate and rewrite Joy programs. This is an incredible notion deserving far greater attention.

I agree, although of course the same is true of any functional language (or at least the side-effect-free subsets thereof), and this has received a great deal of attention in certain circles. It deserves a lot more attention out in the commercial world, though.

Or in the same direction as your comment, consider Guile and Scheme hygenic macros.

Python is the new Java.

Java is the new COBOL.

It's more like "Python is the new BASIC," as it was specifically designed to be used by people new to programming.

Quoting from a page on the origins of Python:

I decided to write an interpreter for the new scripting language I had been thinking about lately: a descendant of ABC that would appeal to Unix/C hackers.

While such a claim isn't necessarily entirely unfounded, I doubt that the intention of the comparison was to equate "Unix/C hackers" with "people new to programming"...

I've decided to stick with Alice even though I intend to make my way through CTM.

Any criticisms are welcome.

(* the example of val v = 9999*9999 causes overflow. Must learn about bigInts in sml *)

In principle you just have to annotate the proper type to get overloading kick in:

val v = 9999*9999 : IntInf.int

In Alice however, overloading for literals has not been implemented yet (see limitations), so that an explicit conversion is required:

val v = IntInf.fromInt 9999 * IntInf.fromInt 9999

(* need to find out how to pattern match on a value in sml??? *)

val n::ns = bla

fun addInt(a, b) = a + b

And perhaps someone can point out the error of my ways on the optimized generacPascal (* in section 1.9 *) which gives a compile error under both Alice and SML-NJ?

I'm pretty certain though that a lot of examples in CTM, being meant to show the multi-paradigm approach, are not easily translatable to Alice.

why don't you use the Inspector for browsing?

(* the example of val v = 9999*9999 causes overflow. Must learn about bigInts in sml *)

In principle you just have to annotate the proper type to get overloading kick in:

   val v = 9999*9999 : IntInf.int

I tinkered around with variations of IntInf.int but still haven't got anything to successfully compile. Specifically, the statement:

   val v = 9999 * 9999 : IntInf.int;

gives a compile error that says it can't unify int with IntInf.int.

(* need to find out how to pattern match on a value in sml??? *)

Not sure what exactly you want, but you can either use case or do a declaration with a pattern:
val n::ns = bla

What started me out on this line of thought was the oz code of:

   L=[5 6 7 8]
   case L of H|T then {Browse H} {Browse T} end

Lot's of ways to get the same functionality in SML, but in playing with it, I had two questions. First, is pattern matching limited to the functions? The Oz code allows you to pattern match the list, assigning the head and tail to local variables automatically. The second question is related to whether expressions can be used in the SML pattern matching.

   fun test []  = "A"
     | test [1] = "B"
     | test x   = "C";

That's pretty straight forward. But what if instead of using a constant in the expression of [1], I instead wanted to match to a variable value or an expression. Anyhow, it's just something I commented on that I want to revisit when I get my ML books in front of me.

This is redundant, you can just say op+ instead of addInt.

The let is simply missing an end.

Doh! (It was getting late). :-)

No worries mate.

Code was changed to use the Inspector - which is much more in the spirit of Oz's Browse.

val v = 9999 * 9999 : IntInf.int; gives a compile error that says it can't unify int with IntInf.int.

case L of H|T then {Browse H} {Browse T} end

This translates directly to

case l of h::t => (inspect h; inspect t)

is pattern matching limited to the functions?

The second question is related to whether expressions can be used in the SML pattern matching.

Only by using guards (an Alice extension to SML):

fun test [x] where (x = y) = ...
| test _ = ...

I guess we should migrate further discussion on such details to the Alice user list, to avoid boring the other readers of LtU. :-)

Note however that you do not really need all the inspects, because the toplevel already prints the results anyway (unlike Oz).

No, actually, they are just sugar for a case.... Only by using guards (an Alice extension to SML):

I guess we should migrate further discussion on such details to the Alice user list, to avoid boring the other readers of LtU. :-)

Speaking of which, I'm kind of wondering whether basing the language on an extension to a current language will present barriers to entry. From the little I've worked with the extensions, I like what I see. But to get a real appreciation for the language, I can't help but think that being proficient in both SML and Oz (as it combines the concepts of one with the structure of the other), means that you really need to study the two in isolation to gain a full appreciation. Kind of like how Objective-C combined C and Smalltalk.

Anyhow, I'll eventually end up posting on the mailing list, but for now I'll let the current thread wind down naturally.

-- Added on Edit --

As I wrote, Alice does not yet implement SML's overloading on literals, so you have to use the explicit coercion I showed in my previous post.

   fun fact 0 = 1
     | fact n = n * fact (n-1);
   fact(IntInf.fromInt(0));

I did not think about it at first, but are you sure that 9999*9999 overflows in int? It shouldn't, and it definitely doesn't for me. If so, please file a bug report.

what's the default file extension for Alice (I'm just using .sml).

I'm kind of wondering whether basing the language on an extension to a current language will present barriers to entry. From the little I've worked with the extensions, I like what I see. But to get a real appreciation for the language, I can't help but think that being proficient in both SML and Oz

Actually, one of the motivations for Alice was to lower these barriers, as many people in the past had been put off by Oz and its syntax too early, or refrained from learning a whole new language just for some specific concepts they were interested in. By basing Alice on something standard we hope to avoid that and make the interesting stuff more obvious.

In principle, being proficient in Oz shouldn't be necessary at all to learn Alice, but of course there is a lack of material introducing the respective concepts with Alice itself, so that a detour through Oz might be necessary.

I assume that this lack of overloading on the constants carries through in the pattern matching and the guards?

Yes, absolutely. And by the way, the difficulty to easily transform overloaded pattern literals into something non-overloaded is precisely the reason that this kind of overloading has not been implemented yet.

Regarding fact, you can circumvent the problem by defining it this way:

fun fact 0 = IntInf.fromInt 1
| fact n = IntInf.fromInt n * fact (n-1)

This gives you fact : int -> IntInf.int, which is good enough because big integers do not make much sense as arguments anyway (would run out of memory). In other situations I do something along the lines of

val n0 = IntInf.fromInt 0
val n1 = IntInf.fromInt 1
fun fact n = if n = n0 then n1 else n * fact (n-n1)

[Note: Very strange, when I first named "n0" and "n1" in the example above "zero" and "one", my posting got rejected because of "suspicious content", provoked - as I found out with try&error - by the line declaring "one". Anybody knows the cause of this?]

The overflow occurs with 9999*9999*9999*9999. For some reason, CTM wants to throw out some really big numbers up front - the other one is Fact(100). Other than showing off Oz's number scaling feature, it's not the kind of numeric range that I'd typically encounter (never had the need for more than 32 bit integers, and this one goes into 54 bits (2^54).

For the sake of comparison, I seem to get the same sort of behavior in SML-NJ.

OK, that makes perfect sense.

For the sake of comparison, I seem to get the same sort of behavior in SML-NJ.

Yes, both use (like most FPLs) a 31 bit int type by default.

Very strange, when I first named "n0" and "n1" in the example above "zero" and "one", my posting got rejected because of "suspicious content", provoked - as I found out with try&error - by the line declaring "one". Anybody knows the cause of this?

I checked, and there's a regexp in the Drupal code which looks for certain patterns of assignment to certain names, including anything beginning with "on". This only applies within things that look like HTML blocks, but if you quote code with PRE or CODE tags, that condition is satisfied. I assume this is to prevent Javascript in messages hooking the event handlers, which have names like onClick.

There must be some other criteria, too, since I was able to insert the below (perhaps because of having administrator status, not sure):

val zero = IntInf.fromInt 0
val one = IntInf.fromInt 1
fun fact n = if n = zero then one else n * fact (n-one)

The options would seem to be Ada/Eiffel on one side, or SML/Haskell on the other.

For example, the tool I use most when breaking a very large ball of mud apart is "grope". A wee ruby script that knows where every file in the system lives and allows me to do fast regex searches on _all_ of them.

What I really want is a tool that understands comment / non-comment, local, file scope and global scope symbols.

The other tool I use a lot is "nm", I pull out all the external defined and undefined symbols from the object files, construct a digraph and manipulate that.

Unfortunately that misses anything that is currently #ifdef'd out of view. But again, these tricks are one way. I can construct a view, I can work out where I want to cut, and then it is back to the text editor and perhaps emacs macros to help me make the cut.

Thread safety in C/C++ is an utter nightmare. The number of ways it can go wrong is amazing. I have constructed tools to find potential races, but still it only finds some, and even those require intensive hands on analysis to determine if they are real, and often require rearchitecting to fix.

I'm looking for a language that, like Joy is analyzable. That I can programmatically wade through megalines of code and make strong statements about them. With C/C++/Java/Ruby all I can do is heuristics. List potential trouble spots for further investigation.

Converting, compiler-like, a human readable form to a machine readable form is the least and weakest thing we need to do with programs. That has taken us to where we are today.

What we need now for large systems is languages that can be analyzed programmatically for a large number of other tasks....

• Visualization.
• Metrics
• Enforcement of architectural policy decisions.
• Discovering and cleaning the architecture of an evolved system.
• Thread safety. (I hate threads, so many ways to get them wrong...)
• Refactoring, both small and large.
• "lint" like static analysis.
• Automated simplification. We have had algebraic simplification for decades, and most code I see can really do with simplifying! (It is amazing how many bugs are revealed when you do so!)
• Cosmetic improvements and layouts.
• Aspect oriented program becomes trivial in a language that is easily analyzable.
• Synchronization of interfaces between systems. (Common trick is to generate both sides from XML, wouldn't it be nicer to tweak interface on either side and be able to automagically reverse engineer it into the common representation.)

Have you looked at Factor? (http://factor.sourceforge.net). It's got the joy of Joy, a bit of Scheme, and generic function based objects with a native code compiler (for x86).