Lambda the Ultimate

Hello all!

I am thinking of writing a research article on typesafe DSLs in Java-like languages. My first (informal) post is available here. I have one more case study in the works, which shows a bit different aspects of typesafe DSLs. Do you know of similar research done for Java-like languages and what conference/journal would you suggest for publication?

Jevgeni Kabanov

pLucid, The Original Lucid interpreter (written by Dr. Tony Faustini) is available at here.

Lucid was the original Dataflow programming language (1976), and influenced many of the subsequent programming languages. pLucid was the first interpreter for Lucid. It was the subject for the paper An eductive interpreter for the functional language pLucid.

It was kindly made available by Prof. Bill Wadge.

Being interested in dependent typed programming for a little while I noticed a slight peculiarity of the field: there are almost no papers on overloading in dependent typed setting.

The only paper is here: Dependent Types with Subtyping and Late-Bound Overloading.

There are a plenty of papers describing techniques for generic programming, like Generic Programming Within Dependently Typed Programming. But no overloading.

In my own opinion overloading is quite important for regular programming and its' absence can be a substantial barrier on entry.

(A little discussion of overloading was here: http://lambda-the-ultimate.org/classic/message1575.html In some implementations a function can return a Set, ie, Type (an example is let (A:* ---- wList A:*) in Generic Programming with Dependent Types, so dependency on value of argument seems to be at least as general as dependence on the type of argument. But again, no one shows how to use it.)

So, the questions are: What precludes dependent typed programming languages to have overloading? And what should one do to work around that?

Linked from the Syllable web site:

Rhope is a new multi-paradigm programming language that uses dataflow and a transaction model to make concurrent programming easy. The first implementation of the language is still in an alpha state, but it's quickly becoming usable for real tasks. This site is generated and served by software written in Rhope.

The current language looks very basic (and simple), but it is still interesting to follow. Of course being dataflow-based it would be a very good candidate for visual programming.

Nothing stunning here, just a basic/simplistic question -

Assuming relational better than hierarchical, for "visibility" of things in languages, are there / could there be a successful approach to visibility of things which is relational, not hierarchical?

C++ has the "friend" visibility keyword, Java and C# don't seem to have a cross-cutting visibility tool. Does C++'s "friend" suffice, or does it have too much of a preference of hierarchical over relational, and/or does it have some land-mine drawbacks (I mean besides the standard chances of abuse)? I guess I was always just queasy with it e.g.

If encountering friend functions for the first time, you might feel slightly uneasy since they seem to violate encapsulation. This feeling may stem from the fact that a friend function is not strictly a member of the class.

By thinking of a friend function as part of the class’s public interface, you can get a better understanding of how friends work. From a design perspective, friends can be treated in a similar way to public member functions. The concept of a class interface can be extended from public members to include friend functions and friend classes.

Hello All,
I have recently started learning Lisp and currently I am struggling to design a function replace-heads, which takes a list-of-lists as one argument and an atom as the second, and returns a list-of-lists in which the first element of each component list has been replaced with the atom passed in. So, for example, (replace-heads '((a b c) (d e) (f g h)) 'x) returns ((x b c) (x e) (x g h)).

I am not able to apply tree recursion method when actually replacing the first element in the last sub list for a given parent node.

Can somebody please help?

Thanks,
AceKnocks

It seems to me that most evaluation strategies are type independent. In other words the evaluation rules are independent of the types yielded by sub-expressions. Is this always the case?

What if we were to write an operational semantics that depended on the type of sub-expressions? Is that a strange thing to do?

For example:


a:fun b:val ::== a(b)
a:val b:fun ::== b(a)


Any help would be much appreciated!

I've heard a lot that writing a function in lisp will yield a function equivalent to any of the built in operators, therefore it is entirely possible to re-create any of the built in operators using lisp code. However, this can't be done in C because of its syntax rules. But if C did use prefix notation then I don't see a reason why you couldn't re-create any of the built in operators using C code. So basically what I am wondering is if it is prefix notation alone that makes this claim true in lisp or is there something deeper going on here that I am not seeing clearly?

The connections between higher-order functions and closures have been discussed here before, and clearly closures make higher-order programming more expressive. However, closures can sometimes make reasoning about space use and efficiency more difficult, as they penalize all higher-order function call sites (absent whole-program compilation).

I wonder if anyone has explored the space of languages with higher-order functions, but without closures. By this I mean that all functions-as-values are restricted to carry no environment, thus reducing them to C-like function pointers. We can add closures back using modules:

module type Fun =
sig
  type ('a,'b) t
  val new: ('a -> 'b) -> ('a,'b) t
  val apply: ('a,'b) t -> 'a -> 'b
end

So it's clear from function signatures whether an operation accept a Fun or accepts a function pointer. The space use and efficiency trade-offs are thus quite clear.

I don't have a good intuition as to how painful this might be to program with however. Eliminating closures clearly decreases expressiveness, but if we keep an expressive ML-like syntax with type inference, we haven't quite devolved to Java-like verbosity.

Have any languages taken this or a similar route?

FringeDC is a group in Washington DC interested in Fringe Programming Languages (Lisp, Haskell, Erlang, Prolog, etc.) www.lisperati.com/fringedc.html

Our next meeting features Brent Yorgey, who is well known in the Haskell community and a contributor to XMonad. For those who don't know, XMonad (a purely functional windows manager) is often lauded (well, by me at least, but others as well :-) as a masterpiece in software engineering. It cleanly marries elegant functional programming code with the ugliest of uglies, the X Windows system. Brent will be giving an intro to Haskell and explain the nuts of bolts of extending XMonad. As an opener, Philip Fominykh will be giving an opening presentation on Zippers, an exotic purely functional data structure popular among Haskellers!

The Meeting is will be held on Saturday, March 22nd. It is hosted by Clark&Parsia, a developer of OWL/Semantic Web reasoning software in downtown DC. After the presentation, we'll grab some food nearby and talk programming languages.

Address:
926 N St NW Rear
Studio #1
Washington DC 20001
Google Map:http://clarkparsia.com/contact

-Conrad Barski, M.D. (cell 202 436 1388)

P.S. We're looking for someone to make a video of the meeting for the interwebs- Bring your camera if you want to help.