user defined types
Ian Clarke
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
or
data Shape
= Ellipse Float Float
| Square Float
| Polygon [(Float, Float)]
A related question would be whether Cat, or a language implemented on
top of the Cat bytecode can support pattern matching?
Sorry if these are dumb questions :-)
Ian.
--
Ian Clarke
CEO, Uprizer Labs
Email: i...@uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
Christopher Diggins
>
> 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
>
> or
>
> data Shape
> = Ellipse Float Float
> | Square Float
> | Polygon [(Float, Float)]
>
Hi Ian,
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.
Cheers,
Christopher
Ian Clarke
> 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!
Thoughts?
Christopher Diggins
>
> On Sat, Jan 3, 2009 at 7:35 AM, Christopher Diggins <cdig...@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.
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.
- Christopher
Ian Clarke
> On Sat, Jan 3, 2009 at 11:49 AM, Ian Clarke <ian.c...@gmail.com> wrote:
>> On Sat, Jan 3, 2009 at 7:35 AM, Christopher Diggins <cdig...@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.
That would be very useful,
Christopher Diggins
>>> 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.
My point is that there is not
>> 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.
>
> That would be very useful,
>
> Ian.
Cheers,
Christopher
Ian Clarke
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.
Christopher Diggins
>
> 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.
I haven't looked into EC2 (http://aws.amazon.com/ec2/). It could very
well be a better way to go.
>>> 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.
>
> Ian.
Great stuff, I am glad we are on the same page.
- Christopher