Hi, perhaps I've misunderstood something but does Cat support user-defined types? I can't see any obvious equivalent in the spec. I'm talking about the type of thing that in Haskell would look like:
data Piece = Pawn | Rook | Knight | Bishop | Queen | King
On Fri, Jan 2, 2009 at 7:51 AM, Ian Clarke <ian.cla...@gmail.com> wrote:
> Hi, perhaps I've misunderstood something but does Cat support > user-defined types? I can't see any obvious equivalent in the spec. > I'm talking about the type of thing that in Haskell would look like:
> data Piece = Pawn | Rook | Knight | Bishop | Queen | King
No this is not a feature in Cat. In the next version of Cat that uses a CVML back-end you will be able to achieve this by using dynamic object-oriented programming techniques. You will be able to create objects using "null", and then manually add and remove fields/methods using an "add_slot" method. This is probably not going to be very pleasant for an end-user. You can however, alternatively use the Heron front-end to CVML which will give a nicer syntax for user-defined types, or you can create your own front-end syntax for CVML.
> A related question would be whether Cat, or a language implemented on > top of the Cat bytecode can support pattern matching?
No to the former. Yes to the latter.
> Sorry if these are dumb questions :-)
No such thing. :-)
> Ian.
Let me help clarify some things, Cat was never really intended as an end-user language. This is now especially true of CVML. I will be providing a Cat-like syntax for CVML, but it will not have a type-checker in the first iteration, and will reflect the structure of the byte-code. This means some things are going to be possible that weren't before like indexing into the stack. This kind of feature will require a rebuilt type-checker / inferer anyway.
So the next generation of Cat is going to be basically an assembly language for CVML. I have nearly completed an optimizing compiler from a high-level infix language to CVML, that has a dynamic object-based type-system like JavaScript, but can also support the definition of classes. As an intermediate step the infix language generates a prefix language that looks suspiciously like Scheme. This means that Scheme/Lisp like languages will be easily targeted to CVML as well.
As far technical questions about what you can do with language syntax, well anything is possible and isn't particularly hard. Programming language implementation is all about reducing high-level features (like pattern matching) to simpler and simpler basic constructions until you end up writing assembly code or byte-code. It sounds to me like you want a Haskell or Scala style front-end to CVML, but I am not sure what your precise needs are. Do you have a sketch of your ideal syntax? How flexible are you with regards to the syntax? Do you care that I provide you with the syntax that I want if I can at least provide you with a decent VM and byte-code compiler?
While all that you request is possible, and relatively easy for someone experienced in programming language implementation, it does add up to a significant number of hours of work, and I unfortunately have a day job that doesn't permit me to work on this as much as I would like (hint, hint).
I don't know how serious you are about Vega, and whether you have some money to invest in the project. If I could work on this full-time, I could definitely produces results more quickly.
On Sat, Jan 3, 2009 at 7:35 AM, Christopher Diggins <cdigg...@gmail.com> wrote: > No this is not a feature in Cat. In the next version of Cat that uses > a CVML back-end you will be able to achieve this by using dynamic > object-oriented programming techniques. You will be able to create > objects using "null", and then manually add and remove fields/methods > using an "add_slot" method. This is probably not going to be very > pleasant for an end-user. You can however, alternatively use the Heron > front-end to CVML which will give a nicer syntax for user-defined > types, or you can create your own front-end syntax for CVML.
Will this support something like Haskell type classes (ie. in the language that will compile to CVML)?
> Do you have a sketch of your ideal > syntax?
Well, its all still rather up in the air, really I'd rather implement Swarm (I think I'm going to go with "Swarm" rather than "Vega") using a pre-existing programming language to ease adoption, but I can't find any suitable languages that support portable continuations.
I'd like to use a language that makes it easy to create DSLs (like Scala and Haskell), this would then allow the creation of a nice web framework (this would occupy a similar place in the stack to Rails, LiftWeb, or Apache Wicket), which makes it easy and pleasant to build web apps.
Ultimately I'd love to create a web-based IDE for Swarm, supporting features like code-completion (I've been spoiled by Eclipse ;). Of course, this IDE would be implemented using Swarm itself. I'm not that familiar with Smalltalk, but from what I hear its approach to IDEs could provide some inspiration here.
> How flexible are you with regards to the syntax? Do you care > that I provide you with the syntax that I want if I can at least > provide you with a decent VM and byte-code compiler?
I don't have strong issues regarding syntax provided that it is flexible enough to create an elegant DSL, much like Ruby, Haskell, or Scala. Of course, simpler is better provided that flexibility isn't sacrificed.
> While all that you request is possible, and relatively easy for > someone experienced in programming language implementation, it does > add up to a significant number of hours of work, and I unfortunately > have a day job that doesn't permit me to work on this as much as I > would like (hint, hint). > I don't know how serious you are about Vega, and whether you have some > money to invest in the project. If I could work on this full-time, I > could definitely produces results more quickly.
Hmmm, well... the situation is this: I did initially think Swarm/Vega might be something I could pursue full-time as it was then unclear whether my current project would pan out. During this time I approached Rackspace to see whether they might be willing to invest in Swarm (one of the founders is a friend of a friend). Rackspace is a very profitable company, but don't have a history of R&D work. I think they'd like to do more R&D.
Our conclusion was that it would be something they'd like to fund, perhaps as an open source project, but they'd need to be convinced that it was achievable since we all agreed that it was very ambitious (distributed garbage collection, load balancing, ensuring it was secure, etc). We agreed that I'd go and think it through some more to try to decide if it was doable, then we'd talk again. That was back in early-September, and shortly afterwards my main project started to do much better, so I put Swarm on the back-burner.
Recently I decided that I'd try to resurrect Swarm as an open source project, although I realized it would be difficult because I'd need to persuade others to do much of the ground-work, since my main project its very demanding of my time.
If this is something you could be in a position to work full-time on, I could potentially go back to Rackspace and see whether they are still interested. I do also have connections to some high-net-worth techie types who might be in a position to put some $$$ into it (unfortunately I don't personally fall into this category yet ;). Of course, before this we'd first need to convince ourselves that this is achievable, and then convince them!
On Sat, Jan 3, 2009 at 11:49 AM, Ian Clarke <ian.cla...@gmail.com> wrote:
> On Sat, Jan 3, 2009 at 7:35 AM, Christopher Diggins <cdigg...@gmail.com> wrote: >> No this is not a feature in Cat. In the next version of Cat that uses >> a CVML back-end you will be able to achieve this by using dynamic >> object-oriented programming techniques. You will be able to create >> objects using "null", and then manually add and remove fields/methods >> using an "add_slot" method. This is probably not going to be very >> pleasant for an end-user. You can however, alternatively use the Heron >> front-end to CVML which will give a nicer syntax for user-defined >> types, or you can create your own front-end syntax for CVML.
> Will this support something like Haskell type classes (ie. in the > language that will compile to CVML)?
I believe so. CVML will support interfaces and duck-typing. AFAIK this is sufficient to implement type-classes, but I haven't studied type classes in depth.
>> Do you have a sketch of your ideal >> syntax?
> Well, its all still rather up in the air, really I'd rather implement > Swarm (I think I'm going to go with "Swarm" rather than "Vega") using > a pre-existing programming language to ease adoption, but I can't find > any suitable languages that support portable continuations.
I think the easiest thing is to start with a JavaScript syntax, and simply tack-on a syntax portable continuations.
> I'd like to use a language that makes it easy to create DSLs (like > Scala and Haskell), this would then allow the creation of a nice web > framework (this would occupy a similar place in the stack to Rails, > LiftWeb, or Apache Wicket), which makes it easy and pleasant to build > web apps.
Well the only "DSL" I have seen in these languages that wasn't a toy was "Ruby on Rails", but lets be honest, it isn't really a DSL. It is a framework. A language which allows the definition of DSLs would require a syntax that has far more flexibility than those languages offer.
> Ultimately I'd love to create a web-based IDE for Swarm, supporting > features like code-completion (I've been spoiled by Eclipse ;). Of > course, this IDE would be implemented using Swarm itself. I'm not > that familiar with Smalltalk, but from what I hear its approach to > IDEs could provide some inspiration here.
This would be an interesting first project.
>> How flexible are you with regards to the syntax? Do you care >> that I provide you with the syntax that I want if I can at least >> provide you with a decent VM and byte-code compiler?
> I don't have strong issues regarding syntax provided that it is > flexible enough to create an elegant DSL, much like Ruby, Haskell, or > Scala. Of course, simpler is better provided that flexibility isn't > sacrificed.
I don't know of any widely used DSLs in these languages. Every DSL I have seen has been simply a toy, or a mislabeled framework. I think the most powerful approach, is to simply construct a translator for whatever syntax you desire into a bytecode. In other words, instead of using a single superlanguage with huge syntactic flexibility, you are going to have more success designing a DSL and targeting a VM.
So my suggestion is, we work on the CVML back-end, we decide on some arbitrary high-level syntax up front. If people want a different DSL or want to hack the syntax, they can just rewrite the code. My experience is that writing DSLs happens very rarely, compared to the average programming task, so it is easier to leave syntax design up to language designers, rather than embedding the machinery directly in the language.
Does this make sense?
I should point out that, some of the meta-programming features that one expect from dynamic languages like Ruby, are present in Heron. I will go into more depth later on.
>> While all that you request is possible, and relatively easy for >> someone experienced in programming language implementation, it does >> add up to a significant number of hours of work, and I unfortunately >> have a day job that doesn't permit me to work on this as much as I >> would like (hint, hint). >> I don't know how serious you are about Vega, and whether you have some >> money to invest in the project. If I could work on this full-time, I >> could definitely produces results more quickly.
> Hmmm, well... the situation is this: I did initially think Swarm/Vega > might be something I could pursue full-time as it was then unclear > whether my current project would pan out. During this time I > approached Rackspace to see whether they might be willing to invest in > Swarm (one of the founders is a friend of a friend). Rackspace is a > very profitable company, but don't have a history of R&D work. I > think they'd like to do more R&D.
> Our conclusion was that it would be something they'd like to fund, > perhaps as an open source project, but they'd need to be convinced > that it was achievable since we all agreed that it was very ambitious > (distributed garbage collection, load balancing, ensuring it was > secure, etc). We agreed that I'd go and think it through some more to > try to decide if it was doable, then we'd talk again. That was back > in early-September, and shortly afterwards my main project started to > do much better, so I put Swarm on the back-burner.
> Recently I decided that I'd try to resurrect Swarm as an open source > project, although I realized it would be difficult because I'd need to > persuade others to do much of the ground-work, since my main project > its very demanding of my time.
> If this is something you could be in a position to work full-time on, > I could potentially go back to Rackspace and see whether they are > still interested. I do also have connections to some high-net-worth > techie types who might be in a position to put some $$$ into it > (unfortunately I don't personally fall into this category yet ;). Of > course, before this we'd first need to convince ourselves that this is > achievable, and then convince them!
> Thoughts?
Thanks for sharing this info with me.
So it sounds like the best plan of attack is to build a prototype that is a proof of concept, and then go back and talk to some people.
My plan is this: - finish the optimizing compiler to CVML for Feb. 6. - submit a paper to the workshop Languages, Compilers, and Tools for Embedded Systems about optimizing CVML for code compactness - finish the C++ version of the VM mid Feb. - finish a VM for CVML written in Python early March - demo distributing computations on the Python VM using the free Google AppEngine service (I have an account set up) - write a JavaScript version of the VM so that CVML can be executed on a browser. - start work on a Vega IDE. - as soon as we have some promising results talk to people. I expect by mid-April we will have an interesting demo.
What do you think?
I have been considering some alternative demonstrations as well. One is to run multiple instances of CVML each on a different hardware thread (e.g. core/processor/whatever).
I can send you a draft of the CVML paper in a couple of weeks, so you can get a better sense of what makes CVML special.
On Sat, Jan 3, 2009 at 5:56 PM, Christopher Diggins <cdigg...@gmail.com> wrote: > On Sat, Jan 3, 2009 at 11:49 AM, Ian Clarke <ian.cla...@gmail.com> wrote: >> On Sat, Jan 3, 2009 at 7:35 AM, Christopher Diggins <cdigg...@gmail.com> wrote: >>> No this is not a feature in Cat. In the next version of Cat that uses >>> a CVML back-end you will be able to achieve this by using dynamic >>> object-oriented programming techniques. You will be able to create >>> objects using "null", and then manually add and remove fields/methods >>> using an "add_slot" method. This is probably not going to be very >>> pleasant for an end-user. You can however, alternatively use the Heron >>> front-end to CVML which will give a nicer syntax for user-defined >>> types, or you can create your own front-end syntax for CVML.
>> Will this support something like Haskell type classes (ie. in the >> language that will compile to CVML)?
> I believe so. CVML will support interfaces and duck-typing. AFAIK this > is sufficient to implement type-classes, but I haven't studied type > classes in depth.
Will it still be statically typed (like Haskell, Scala, unlike Ruby)? The static typing of Cat was one of the things that I found initially attractive. It would be a shame if this had to be thrown away in order to achieve more sophisticated programming language features like type classes. You may also want to look into Scala's "implicits", since apparently these achieve similar things to Haskell's type classes.
> I think the easiest thing is to start with a JavaScript syntax, and > simply tack-on a syntax portable continuations.
You mean a full ECMAScript syntax - or just something like JavaScript (C-like syntax, dynamic typing)?
> Well the only "DSL" I have seen in these languages that wasn't a toy > was "Ruby on Rails", but lets be honest, it isn't really a DSL. It is > a framework. A language which allows the definition of DSLs would > require a syntax that has far more flexibility than those languages > offer.
Well, I suppose RoR is a DSL *and* a framework, or perhaps a framework, part of which is a DSL. I don't think there is a bright line between them.
> I don't know of any widely used DSLs in these languages. Every DSL I > have seen has been simply a toy, or a mislabeled framework. I think > the most powerful approach, is to simply construct a translator for > whatever syntax you desire into a bytecode. In other words, instead of > using a single superlanguage with huge syntactic flexibility, you are > going to have more success designing a DSL and targeting a VM.
Yes, that may indeed be a good approach. I would say that the flexibility afforded by Haskell and Scala are sufficient for the type of DSL/Framework I had in mind.
> So my suggestion is, we work on the CVML back-end, we decide on some > arbitrary high-level syntax up front. If people want a different DSL > or want to hack the syntax, they can just rewrite the code. My > experience is that writing DSLs happens very rarely, compared to the > average programming task, so it is easier to leave syntax design up to > language designers, rather than embedding the machinery directly in > the language.
> Does this make sense?
Yes, however I would hope that the bytecode could support static typing of these higher level language features, rather than just abandoning compile-time type-checking for these. IMHO static typing with good type inference is the future.
> So it sounds like the best plan of attack is to build a prototype that > is a proof of concept, and then go back and talk to some people.
> My plan is this: > - finish the optimizing compiler to CVML for Feb. 6. > - submit a paper to the workshop Languages, Compilers, and Tools for > Embedded Systems about optimizing CVML for code compactness > - finish the C++ version of the VM mid Feb. > - finish a VM for CVML written in Python early March > - demo distributing computations on the Python VM using the free > Google AppEngine service (I have an account set up)
Hmmm, why Python here? Does a Python interpreter work for us (given that it will be far slower than the C++ version probably).
> - write a JavaScript version of the VM so that CVML can be executed on > a browser.
That could be useful for doing stuff like GWT - breaking down the client-server.
Of course, if the only priority was Vega, then I'd probably skip the JavaScript and Python implementations of the VM.
> - start work on a Vega IDE. > - as soon as we have some promising results talk to people. I expect > by mid-April we will have an interesting demo.
> What do you think?
Good, however we could approach them earlier in the process. I don't think they'd need a working prototype to greenlight this.
> I have been considering some alternative demonstrations as well. One > is to run multiple instances of CVML each on a different hardware > thread (e.g. core/processor/whatever).
> I can send you a draft of the CVML paper in a couple of weeks, so you > can get a better sense of what makes CVML special.
>>> Will this support something like Haskell type classes (ie. in the >>> language that will compile to CVML)?
>> I believe so. CVML will support interfaces and duck-typing. AFAIK this >> is sufficient to implement type-classes, but I haven't studied type >> classes in depth.
> Will it still be statically typed (like Haskell, Scala, unlike Ruby)?
It will support both static and dynamic typing.
> The static typing of Cat was one of the things that I found initially > attractive. It would be a shame if this had to be thrown away in > order to achieve more sophisticated programming language features like > type classes.
Its not.
> You may also want to look into Scala's "implicits", > since apparently these achieve similar things to Haskell's type > classes.
So are OCaml signatures, I believe.
>> I think the easiest thing is to start with a JavaScript syntax, and >> simply tack-on a syntax portable continuations.
> You mean a full ECMAScript syntax - or just something like JavaScript > (C-like syntax, dynamic typing)?
I was thinking JavaScript-like.
>> Well the only "DSL" I have seen in these languages that wasn't a toy >> was "Ruby on Rails", but lets be honest, it isn't really a DSL. It is >> a framework. A language which allows the definition of DSLs would >> require a syntax that has far more flexibility than those languages >> offer.
> Well, I suppose RoR is a DSL *and* a framework, or perhaps a > framework, part of which is a DSL. I don't think there is a bright > line between them.
>> I don't know of any widely used DSLs in these languages. Every DSL I >> have seen has been simply a toy, or a mislabeled framework. I think >> the most powerful approach, is to simply construct a translator for >> whatever syntax you desire into a bytecode. In other words, instead of >> using a single superlanguage with huge syntactic flexibility, you are >> going to have more success designing a DSL and targeting a VM.
> Yes, that may indeed be a good approach. I would say that the > flexibility afforded by Haskell and Scala are sufficient for the type > of DSL/Framework I had in mind.
>> So my suggestion is, we work on the CVML back-end, we decide on some >> arbitrary high-level syntax up front. If people want a different DSL >> or want to hack the syntax, they can just rewrite the code. My >> experience is that writing DSLs happens very rarely, compared to the >> average programming task, so it is easier to leave syntax design up to >> language designers, rather than embedding the machinery directly in >> the language.
>> Does this make sense?
> Yes, however I would hope that the bytecode could support static > typing of these higher level language features, rather than just > abandoning compile-time type-checking for these. IMHO static typing > with good type inference is the future.
I agree, but I would take it a step further and say that mixing static and dynamic typing is the future. A language should infer types where it can and where necessary. Programmers should provide as much information as they feel like.
Anyway, as for static typing of the byte-code, I have already proven that it is possible with the original C# Cat interpreter. The CVML byte-code is slightly different because it uses dependent types. I do plan on rebuilding a type-inferer for CVML, but I don't consider it urgent compared to getting everything else working and rock-solid. Static type checking of byte-code is a relatively easy problem.
>> So it sounds like the best plan of attack is to build a prototype that >> is a proof of concept, and then go back and talk to some people.
>> My plan is this: >> - finish the optimizing compiler to CVML for Feb. 6. >> - submit a paper to the workshop Languages, Compilers, and Tools for >> Embedded Systems about optimizing CVML for code compactness >> - finish the C++ version of the VM mid Feb.
>> - finish a VM for CVML written in Python early March >> - demo distributing computations on the Python VM using the free >> Google AppEngine service (I have an account set up)
> Hmmm, why Python here? Does a Python interpreter work for us (given > that it will be far slower than the C++ version probably).
The Python interpreter will indeed be much much slower. In fact we could probably improve Python performance by generating CVML from it instead of the current byte-code used by the primary implementation.
The rationale is that Google App Engine service (http://code.google.com/appengine/) only currently supports Python. I think that Google App Engine it would be an easy, cheap, and effective way to test CVML in a real distributed environment. I am interested in getting my project on the radar of Google, because I think the CVML project has a huge long-term potential for them.
>> - write a JavaScript version of the VM so that CVML can be executed on >> a browser.
> That could be useful for doing stuff like GWT - breaking down the client-server.
> Of course, if the only priority was Vega, then I'd probably skip the > JavaScript and Python implementations of the VM.
How would you build the Vega IDE, if you didn't have support for CVML on JavaScript? Alternatives I can think of are, translate directly from the Vega syntax to JavaScript, or target CVML to the Java VM. Any other ideas?
>> - start work on a Vega IDE. >> - as soon as we have some promising results talk to people. I expect >> by mid-April we will have an interesting demo.
>> What do you think?
> Good, however we could approach them earlier in the process. I don't > think they'd need a working prototype to greenlight this.
Thats cool. I am swamped for the moment though getting everything working for my paper. So the month of January is going to be quiet for me, but trust me that things are moving ahead quickly. I just don't have time to announce or release intermediate versions of my work
>> I have been considering some alternative demonstrations as well. One >> is to run multiple instances of CVML each on a different hardware >> thread (e.g. core/processor/whatever).
>> I can send you a draft of the CVML paper in a couple of weeks, so you >> can get a better sense of what makes CVML special.
Going to try to trim this down, if I have cut something out it means I agree/understand :-)
> The rationale is that Google App Engine service > (http://code.google.com/appengine/) only currently supports Python. I > think that Google App Engine it would be an easy, cheap, and effective > way to test CVML in a real distributed environment. I am interested in > getting my project on the radar of Google, because I think the CVML > project has a huge long-term potential for them.
Hmm, of course its your decision, although doing a Python implementation just in the hope that it piques Google's curiosity seems like a lot of effort for a long-shot. Have you spoken to Google, or do you have some other reason to think that this would be worthwhile?
EC2 supports any platform and language today - which IMHO makes it far more useful than Google AppEngine, I'd be more inclined to focus on it.
>> That could be useful for doing stuff like GWT - breaking down the client-server.
>> Of course, if the only priority was Vega, then I'd probably skip the >> JavaScript and Python implementations of the VM.
> How would you build the Vega IDE, if you didn't have support for CVML > on JavaScript? Alternatives I can think of are, translate directly > from the Vega syntax to JavaScript, or target CVML to the Java VM. Any > other ideas?
You are right, the Java IDE would require some kind of JavaScript solution, and a GWT-like approach to JavaScript that hid the client-server barrier from the programmer would be a really wonderful approach to JavaScript. That is actually an idea I'd considered separately, but not in the context of Swarm. It makes a *lot* of sense.
On Sun, Jan 4, 2009 at 6:47 AM, Ian Clarke <ian.cla...@gmail.com> wrote:
> Going to try to trim this down, if I have cut something out it means I > agree/understand :-)
>> The rationale is that Google App Engine service >> (http://code.google.com/appengine/) only currently supports Python. I >> think that Google App Engine it would be an easy, cheap, and effective >> way to test CVML in a real distributed environment. I am interested in >> getting my project on the radar of Google, because I think the CVML >> project has a huge long-term potential for them.
> Hmm, of course its your decision, although doing a Python > implementation just in the hope that it piques Google's curiosity > seems like a lot of effort for a long-shot. Have you spoken to > Google, or do you have some other reason to think that this would be > worthwhile?
The primary interest in using Google App Engine and Python was the ease of implementation of an actual distributed system, rather than a simple mock-up. I agree that the primary reason should not be to pique Google's interest. I am not fixed on this. While I don't think that a Python VM would be hard to build, it would never be very efficient.
> EC2 supports any platform and language today - which IMHO makes it far > more useful than Google AppEngine, I'd be more inclined to focus on > it.
>>> That could be useful for doing stuff like GWT - breaking down the client-server.
>>> Of course, if the only priority was Vega, then I'd probably skip the >>> JavaScript and Python implementations of the VM.
>> How would you build the Vega IDE, if you didn't have support for CVML >> on JavaScript? Alternatives I can think of are, translate directly >> from the Vega syntax to JavaScript, or target CVML to the Java VM. Any >> other ideas?
> You are right, the Java IDE would require some kind of JavaScript > solution, and a GWT-like approach to JavaScript that hid the > client-server barrier from the programmer would be a really wonderful > approach to JavaScript. That is actually an idea I'd considered > separately, but not in the context of Swarm. It makes a *lot* of > sense.
