Lambda the Ultimate

It seems to me that there are some E/DSLs which work well (well enough, sometimes debatable) such as Makefiles. Then there are situations where people have E/DSLs that maybe even sound good, but end up not really working out as intended; the abstraction cannot fail to be come leaky but fast. I wonder if "business rules" tend to fall into the latter category.

Might anybody have thoughts on what tells you when an E/DSL can work? Or what approach one should take given the nuances of a particular situation? Or at least what are the aspects involved? There are some situations where you really can hand it over to non-programmers and live to tell the tale, and others where doing so is a quick route to doom.

Thanks for any thoughts.

I have been looking for a language that includes the following form of resolution, but have not yet come to one.

Given a function f: a -> b, and a list l: [a], I would like for the language to consider "f l" a valid expression. In particular, I would like it to automatically "lift" f to be typed as f:[a] -> [b] by rewriting "f l" as "map f l". In general, given a functor F : a -> F a, a function f : a -> b, and value v : F a, I would like for the expression "f v" to be rewritten as "F(f) v : F(b)".

In addition, a multivariable method such as + : double -> double -> double, would lift based on the types of its arguments. Examples:
x, y: Id double |- (x + y) : Id double
x, y: [double] |- (x + y) : [double]
x, y: Interval double |- (x + y) : Interval double
x, y: Dist double |- (x + y) : Dist double
x: Dist double, y: Id double |- (x + y): Dist double
etc...

I understand that all of this can be done by augmenting the code to be written in terms of do notation (almost, these are just plain functors, not monads), but I want a language that does that for me: do x < - a, y <-b, return $ x + y (is equivalent to) a + b. If such a language doesn't exist, can I get suggestions on best/easiest ways to accomplish this. I have considered using a preprocessor/modifying the type resolution process to include the additional code generation for an existing language, but I am not sure if there are other options/which is better. I wrote the above in Haskell notation just for communication purposes. OO languages would be appreciated as well.

Many thanks,
Rob

From wikipedia:

[Static typing] allows many errors to be caught early in the development cycle.

Statically typed languages have another, maybe even more important, advantage: clearer error messages.

Can you spot the error in this code:

def print_all(books):
  for book in books:
    print_book(books)

In a dynamically typed language you might get an error like Undefined method `title` for Array in file print_book.xyz on line 2, if print_book is implemented like this:

def print_book(book):
  print(book.title)
  print('----------')
  print(book.summary)

A statically typed language would give you a more helpful error message print_book wants a Book but you passed an Array in file print_all.xyz on line 3.

Now suppose that you fixed print_all() but made a mistake in print_book. For example, books don't have summaries but descriptions. So the correct code is:

def print_book(book):
  print(book.title)
  print('----------')
  print(book.description)

In this case the error messages will be similar for statically and dynamically typed languages: "Undefined method `summary` for Book in print_book.xyz on line 4".

So the statically typed language 'knows' where the error is. In the first case it's print_all's fault: it passed the wrong value. In the second case it's print_book's fault. Dynamically typed languages don't know where the error is. They usually give you a stack trace and some information on what went wrong in the deepest call in the trace. This is annoying, especially if you are calling library functions not written by you.

What I would like to know is

- Are there cases where statically typed language are wrong about the location of the error? Does this happen in practice?
- Is it possible to guess where the error is in dynamically typed languages, and how?

(If this has already been discussed here, and I assume it probably has although I haven't been able to find such a discussion by search, please be so kind as to point me in the right direction.)

It seems like most languages come up against the operator precedence problem and take one of these two choices:

1. Make an operator precedence table. (C and many, many others)

pro: assigns meaning to 2 + 3 * 7 = 23 (although if you really like 35 or dislike the normal rules, you can have that interpretation too)
con: readers have to know the precedence table to mentally arrive at the same parse tree that the parser does

2. Forget the whole thing, and always make left (or right) deep ASTs. (lisp, APL, many others)

pro: easy to remember
con: while this is much easier to remember, you still need to know that this is the rule, when coming across it for the first time

I'm wondering about the (less-explored?) third option, and would appreciate information about languages that have taken it, or papers exploring it, or just peoples' thoughts:

3. Forget the whole thing, and _always require explicit grouping_ (at least when properties of the operators in question can't be used to arrive at a "don't care" conclusion).

pro: easy to remember, and easy to mentally parse even if you are unfamiliar with the rules
pro: enforces the (common?) practice of using grouping to communicate intent
con: you have to write either 2 + (3 * 7) or (2 + 3) * 7 (although potentially a clever editor could offer you a choice of candidate interpretations when what you write is ambiguous)

Note that we can use the associativity of + to allow expressions like 2 + 3 + 7 because we are indifferent between (2 + 3) + 7 and 2 + (3 + 7). Similar observations apply to a number of other common operators.

Note also that this doesn't completely eliminate operator precedence, since we still need ( ) to bind more tightly than +, for example. This looks like a matter of degree more than an iron-clad rule, so I'm hoping to avoid stepping in a bees' nest here :). Some might argue to relax the rules even further and allow tight bindings for unary negation, which I think makes good sense, since -x + 2 might not be likely in practice to be confused with -(x + 2).

It's possible to write an LALR (and possibly simpler?) grammar that deals with all of this. I'm still trying to wrap my head around techniques for generating sensible errors from parsing failures, so I'm not sure of the extent to which it is possible to give intelligible error messages.

Is this idea hopeless? Misguided? Already in 17 languages I should have heard of? All of the above?

The short version is that they let you deploy "Arrows" over the network. The long version makes reference to Lamport and touches on the use of theorem provers in their system.

Hi,

I want implement a language similar to pascal with focus on more flexibility and ease of use and compatibility with C constructs.
With this in mind too, I've finished a course on theoretical Informatics at a German "Fachhochschule".
I've also bought Pascal Creator Wirth's cheap book on Compiler creating and started working with it. The book is about creating Oberon-0, an Oberon subset, with self made parsing and tokenizing tools written with Oberon. These tools translate to a RISC language similar to MIPS. This for me is very difficult, for I've little assembler knowledge only in Motorola 68K. This assembler appears much easier than Wirth's RISC lang, f. e. has certain ops for function prologs and epilogs.
On the other hand, C as an output language would not suit my needs probably.
So what do you recommend? Which language is used in Ahos books on compiler writing? How about UCSD Pascal P-Code? Or Forth?
And which books about compilers would also be useful for me? I especially would appreciate a book with not to difficult exercises and a solutions appendix.

Regards, Ludwig

[As seen on comp.lang.scheme]

I think the rationale is that Forth comes on controllers, but you might want to do some metaprogramming, so put the 2 together.

[edit: fixed hyperlink]

Doing computational linguistics, I've passed through several languages and settled on Python as the most convenient thing so far for text processing. I've also read a lot about the attractions of functional programming and have wanted to try applying it to my own work.

However, whenever I see FP application to things like string manipulation and regexes (e.g. in Haskell), it seems horribly messy to me, done just to show that it can be, not because it's a good idea.

Am I the victim of bad examples or is text processing something that just shouldn't be done with a functional language?

Hello, there.

This actually is my first post here, but I've been reading LtU for about a year.

Background: I am implementing a small, general purpose procedural language, mainly for gaining some knowledge and insight into subject. I am using ANTLR for parser/lexer generation (Java-ish), and, don't laugh - PHP as a output - mainly because I feel rather familiar with it, and also because I intend to use this language for web - webserver served. So far I have done basics - overall structure, function declaration/compile time argument checking, general language statement (if, for, etc.) implementation.

Question: What are the reasons for constants (like - define("SOME_CONST", "My Fancy Value"); - PHP) in languages that do not compile directly to machine code? As for my language, it would seem logical to use functions (parameterless) returning constant values instead of adding another "subsystem" for constants. Not that I am too lazy, to do it, just wondering if there are any other reasons, asaide from potential speed-up? Am I missing some point?

Thank You,
Krists

Java's enhanced-for loop means you don't easily know what item is currently used out of the collection when you stop in the debugger, because there isn't an index any more. (You can laboriously look for a matching reference value in the collection I guess.) Seems like use of functional approaches such as map() or filter() must 'suffer' from the same issue. Is it the case that debugging is very different than developing? The former seems to want to be able to reveal any and all information, the latter to hide as much as possible. Are there languages which somehow manage to do a great job at serving both masters?