Seems great. Could you share some samples and tutorials (not a huge support site, just so we'll get how it goes).

By on 1/18/2012 12:06 PM ()

Currently the most useful learning tool is the Aml code in Aml's Stdlib files (under Aml/Bin/Stdlib/). I built a little TextPad syntax file (under Aml/Plugins/TextPad) that can be installed for nice syntax highlighting when reading them. I think you may have to specify an Aml document type to make TextPad use the syntax file, though.

There's additionally the AmlSpec.rtf file (in Aml/Documentation/) that describes how the language works. If you're familiar with lisps, it should be straight-forward. Since I've only started working on the Language Module feature, the only thing you can do in AML is evaluate purely functional expressions like those in the Stdlib. This is an extremely early release, and I will prioritize some tutorial stuff once I get the LM and DOL stuff stood up. In fact, the entire experience of that AML release will be as a tiny simulation that you can play around with and modify as a learning experience.

I'd love to find someone to help in creating and maintaining the type of samples and tutorial you suggest because it takes a huge bite out of development time.

Anywho, let me know if the current resources are not enough to start playing around. I can prioritize a tutorial for the next week if needed.

Cheers!

By on 1/18/2012 12:34 PM ()

Wow, it's been a month and a half since I start implementing AML! Fortunately I'm only about a week away from releasing the pre-alpha of the base language. There will still be some missing pieces, and less safety than there will be in the final version, but hopefully someone out there can hack around on it and provide some feedback.

The Language Module part of AML will be developed next in tandem with DOL. Because DOL is non-trivial, it could take a month or two to stand these up. I could release the LM stuff early, but I don't trust the design until it's proved out with DOL. Things are progressing well, but it's a good amount of work left to do.

Please let me know if you are interested in looking at it, and how you would expect it to be made available to you. My e-mail again is bryanedds@yahoo.com

Cheers!

By on 12/19/2011 1:33 PM ()

Hey again all! Project is proceeding quite well. I'm starting to get an idea of the scope of the thing. I am becoming more certain that I will need help in three area to get the project out swiftly -

1) I need someone to build the static contract analyzer. This requires some very interesting programming that I don't really have much experience in. I would love to do it myself for the education, but that's not sufficiently expedient.

2) I need someone to expose the language for use in Visual Studio 2010 Integrated a la F#. Step debugging, syntax and error highlighting, and name completion would be so great. Again, should be pretty enlightening programming.

3) I need someone to write sample projects and tutorials on the base AML language as well as DOL. This should be great fun for people who like to play around and document their results.

This is mostly me thinking out loud, but if anyone would like to discuss helping, please let me know here or at bryanedds@yahoo.com.

Cheers!

By on 12/3/2011 10:48 AM ()

Well after spending a few days on implementation, I've got a turing-complete interpreter up and running. Man things move FAST in F#! Wonderful! Still, much much work left.

However, alongside implementation, I've been re-reading SICP. I realized that in light of scheme's symbolic programming model, this language is superfluous (as are most other languages, interestingly). The only real advantages of it is that it is purely functional and it is convenient to use as a layer above .NET, and has static contracts. Nonetheless, I should be really handy when you want to layer your application that way and want more safety. You can keep any imperative DSL implementation code down in .NET code and built the declarative stuff in AML. It will be really nice, especially if you can't convince your team to go as far as adopting a lisp for your DSLs.

Great fun!

By on 11/19/2011 11:08 AM ()

Have you tried PLT Racket? It has a neat multi-stage macro system where macros compile separately and safely compose. It is one of the easiest to start with environments for new language experimentation. If you are a staunch typed programmer or MLer, I would go the camlp4 or TemplateHaskell way instead.

It might well pay off to experiment with your ideas in an existing system rather than creating one from scratch.

By on 11/2/2011 6:43 AM ()

Hi Anton! I am a big fan of the PLT tech, but I must admit a bias to building this tech from scratch. I've had an itch to implement a language from scratch for a couple of years. That coupled with the great "Write Yourself a Scheme in 48 Hours" papers (both for Haskell and F#), I feel I will have a great deal of fun using that approach.

As for typing (and as an aside), a part of the thesis I wish to put forward is that AML, as a dynamic language using code contracts, can be as safe and machine-efficient as static languages. A contract analyzer should be able to run over AML code and verify it before running or compiling it. A compiler can then take the static contracts as optimization hints.

As for Haskell (also an aside), I have trouble accepting it for everyday use as it's just to difficult for me to keep switching computation contexts needed to deal with functors / applicatives / monads, etc. I prefer the looser type system of F# that doesn't constantly force me to think up and down the computation dimension.
It's just too distracting from the actual problems I'm trying to solve. Just a personal preference at this time.

Cheers!

By on 11/2/2011 8:49 AM ()

Bryan,

I wish you good luck with the project.

Just as another 2 cents from me: there is at least one sense in which type systems are vastly superior to contract systems. Type systems provide a machine-checked way to reason about correctness properties of functions for every possible input.

Suppose you develop a library and test it at work, then send to the client to run on client's data. With a type system you get an early (compile-time) detection of the problem. A contract system, on the other hand, would only detect it later, when the client happens to call the function with an unfortunate input value. That makes for angry clients.. Also it means that errors can go undetected for years.

The caveat of course is that proving is difficult. ML and even Haskell type systems allow to prove only relatively simple properties. And then going further, to Coq and AGDA is not for the faint of heart.

Anton

By on 11/2/2011 12:44 PM ()

Thanks Anton!

So great discussion, but I want to point out one thing about AML that I think you've overlooked. Though the type system is dynamic, the contract system is mostly static. The static contracts in AML allow an external program to analyze AML code and check its non-dynamic contracts. This means that you can find errors in AML code without running or compiling it. This gives you nearly as much safety as static languages.

The surprising fact is that you do not need a statically typed language to have a static contract system or a lot of static safety. AML contracts are in some ways more powerful and safe then typical static type system. In a typical static language you can only require the type of a parameter to be an int, but with static contracts, you can require that a parameter is not only an int, but an int in some arbitrary range. Using predicates like this gives AML a checking system of power somewhat similar to ADGA's set-theoretic type system, but without the learning curve (though it's more comparable to C# code contracts).

So long as the static contract analyzer is run before executing or compiling the AML code, you have nearly the same safety and potential efficiency as a static language. The potential efficiency comes from a compiler that leverages the static contracts as optimization hints; if a parameter can only be made an int due to its static contract, we only allocate a single register.

Further, if you don't want all the strictness required by static contracts, you can simply eschew the safety and efficiency of statically contracted code by eschewing the analyzer entirely and having the static contracts get checked at run-time.

I think that a dynamic language with a static contract system might be a way to win the best of both worlds, and provide a knob on the code's overall strictness according to the developer's most pressing needs.

Edited on Feb 15, 2012 for accuracy.

By on 11/2/2011 1:58 PM ()

You are speaking my language. Have you had a look at what Mozilla is doing with their contracts.coffee dialect of coffeescript? This sounds very similar. Are you looking for contributors, as I would be interested in helping a bit just to exercise some of these ideas.

By on 11/8/2011 11:06 AM ()

I'd be glad to have some help if you've got a bit of spare time. Contact me at bryanedds@yahoo.com please.

Static contracts in a dynamic language seem quite possible, but the implementation details are yet murky. Instead of building a prover, I guess we would be building more of a 'disprover'. We don't need to prove a dynamically-typed program correct or terminating. Rather we only need to prove it incorrect for a given set of specifications as defined by its contracts. It seems that this would make life a lot easier for the static contract checker. But we'll see :)

BTW, I updated the document in the top post. I built a concept of protocols on top of multifunctions, which are built on top of static contracts. That would be something to peer at as well.

By on 11/9/2011 7:48 AM ()

Apologies, I was thinking of contracts as they are in PLT Racket.

So your contracts start to sound like proof-carrying code to me. The best forum I know to discuss this is Lambda the Ultimate (much more knowledgeable people there).

I glanced through the RTF file but it seems to concern mostly syntax. Do you have a semantics? An abstract syntax and interpreter (in say F#) for both the code itself and its contracts would do nicely to communicate the semantics.

I'd postpone further discussion until we have this semantics to look at. You make these contracts sound too good to be true. There must be a catch, like contract checking becoming undecidable.

By on 11/2/2011 7:02 PM ()

You've got me here ;) The semantics are mostly in my head. This means that it might not actually work out. I could document the semantics, but I think it would be easier to just implement the language in F# and let them fall out. I suspect the contract checking will be less than mathematically rigorous as they are literally just a set of predicate expressions. But if it works for C# code contracts, I can't see why it wouldn't work here.

I hope to have something to play with soon :)

By on 11/2/2011 7:23 PM ()

Several points both on FPish and your specifications:

  • The tagging system on FPish is comma-based, that means that the tag text you entered should have been "f#, language, meta, declarative" (spaces to the left or right of the tags are ignored). You can still fix it, would help if you do.
  • FPish fully supports conversation-like topics, just everyone should remember to click the right Reply button (click on the button on the most relevant post you are replying to).
  • Even though there are people who claim simulations and UI should be done with imperative languages, I think it is clear that declarative languages have what to offer, and a nice example is of course XAML. With a good enough DSL system (which is what you propose), anything can be done declaratively.
  • I personally dislike the syntax you've chosen, but it doesn't mean you shouldn't use it. S-expressions are great (and perhaps you should consider just used Common LISP for your plans, or maybe extend it a bit), but I think you've overcomplicated the syntax. For example, you have #[1 2 3] and #<1 2 3> and #{:a 1 :b 2}. These could be simply converted into (list 1 2 3), (array 1 2 3) and (record :a 1 :b 2), thus simply being part of the base library and not part of the syntax.
  • I remember seeing a few months ago a language named M (I think developed by MSR) which allows you to do something similar. If I remember right, it is a high-level standalone Yacc-like language, probably with .NET interop. You should at least check it out.
  • Don't be afraid to publish partial demos before you're done. We would all like to see how this project is doing, and maybe even use it.
By on 11/2/2011 4:16 AM ()

Just a short note, we addressed the issue of comma- or space-separated tags, it will be out shortly.

By on 11/4/2011 12:32 PM ()

Thank you Ramon for your notes!

Points 1 and 2 - Thanks! I'll fix and note this.

Point 3 - Thanks for some confirmation on this. I hope to demonstrate the OOP can be subsumed with a declarative object systems in most cases.

4 - The syntax is suboptimal. I much prefer an ML-style syntax, but I think it's better to get something working ASAP to prove the underlying semantic thesis. I may make the syntax of the language pluggable or replace it with something more ML-like in a later version. Thanks for the notes on overuse of symbols - I'll try to simplify the syntax in the direction you recommend.

5 - I will look at M.

6 - I will publish stuff ASAP. I'm not sure if I should open source it or not though since perhaps some company could be interested in funding it. Thoughts?

Cheers and thanks Ramon!

By on 11/2/2011 7:55 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper