Thank you and a couple of questions
portly....@googlemail.com
First of all, thank you for a really interesting language. I've just
started playing with it and I think it has real potential. I've only
really played a little with Java and am currently learning it so I can
better understand the workings of Magpie.
I have a couple of questions.
1. Currently Magpie is interpreted - do you think it would be possible
to compile to to the JVM? Is that in the plans anytime soon?
2. I like the fact that you can have left and right arguments with
methods but was curious as to why you had to have a bracket for the
right arguments - is this just a quirk of the language or is it to
enable parsing and understanding?
3. Floating point numbers are not supported - is this because they are
difficult to implement or just something that you need to get around
to at some point?
once again thanks for a great language
Dave
Bob Nystrom
<portly....@googlemail.com> wrote:
> 1. Currently Magpie is interpreted - do you think it would be possible
> to compile to to the JVM? Is that in the plans anytime soon?
Good question. I wrote it in as an interpreter in Java mostly as a
matter of convenience. It was the quickest platform for me to start
prototyping language features. Now that the whole
patterns/classes/multimethods core is for the most part stable, I've
started thinking about what a "real" implementation of the language
will look like.
I don't know what other people think, but I'm not personally strongly
tied to the JVM. I don't mind it, but it doesn't do a whole lot for
me. I'm still poking around and investigating, but right now I'm
leaning towards:
1. Bytecode interpreter written in C++.
2. Bootstrapped source->bytecode compiler written in Magpie.
My reasoning is:
1. I know C++ pretty well.
2. Lots of other people do too.
3. It lets us have a standalone magpie executable that doesn't rely on
another VM or other stuff to be installed. No JVM dependency.
4. Very fast startup (which the JVM really sucks for).
5. Leaves potential for using LLVM or a JIT on the back-end.
6. Actual C++ code should be relatively small since most of the work
is in the compiler.
I'm still tinkering, so this isn't The Way Forward for Magpie or
anything, but I like the idea of ditching the JVM and having something
that feels a little smaller and more standalone like Lua/Python/Ruby.
> 2. I like the fact that you can have left and right arguments with
> methods but was curious as to why you had to have a bracket for the
> right arguments - is this just a quirk of the language or is it to
> enable parsing and understanding?
Great question!
It's a strange mixture of historical baggage + some usefulness.
Magpie used to be a single dispatch OOP language. At the time, the
argument on the left (the receiver) really meant something different
than the one on the right (the argument) since the receiver was used
to look up the method. That's why most OOP languages are asymmetric
there.
I borrowed the "receiver method(arg)" syntax from Io since it's
lightweight and reads well. When I later ditched single dispatch in
favor of multimethods, I didn't change the syntax.
I still really like having an infix syntax, but you're right to notice
that it's syntactically asymmetric when the semantics are symmetric.
I'm up for changing the syntax, but I haven't figured out something
that I like better than the current one. The problem is this. Let's
say we don't require brackets on the right. How do we parse this:
foo bar bang baz zoop
Io says:
((((foo bar) bang) baz) zoop)
I.e. a series of getters.
Scala says:
foo.bar(bang).baz(zoop)
I.e. alternating methods and arguments.
Personally, I always found Scala's interpretation really confusing, so
I went with Io. But that means if you do want to pass an argument to a
method, that needs to be indicated somehow: hence parentheses.
It's a bit of a drag because there's places where not requiring
parentheses would still be clear and would look really nice, like:
for 1 to 10 do ...
Where "to" is a method that takes "1" and "10" on the left and right.
There may be a better syntax that gives symmetry and makes things like
"1 to 10" work without ending up in Scala's word soup, but I haven't
spent a lot of time thinking about it yet. If you have ideas, let's
hear them. :)
> 3. Floating point numbers are not supported - is this because they are
> difficult to implement or just something that you need to get around
> to at some point?
Just haven't gotten around to it. In particular, I haven't figured out
what kind of numeric tower it should have. I'd like something with big
number support right in the language, since that seems like a good fit
for a high-level language like Magpie, but I haven't put any effort
into it yet.
> once again thanks for a great language
Thanks for trying it out!
- bob
portly....@googlemail.com
thank you for such a quick response. I'll carry on learning Java and
trying to work out how Magpie works so hopefully in the future I'll be
able to contribute.
Kind Regards
Dave
On Aug 10, 9:23 pm, Bob Nystrom <munificent...@gmail.com> wrote:
> On Wed, Aug 10, 2011 at 12:13 PM, portly.shor...@googlemail.com
Mike Austin
I'll be reading a bit more and hopefully playing with it a bit (but Battlefield 3 comes first :)
Regards,
Mike
Bob Nystrom
> I also want to say good job on Magpie. It has some interesting features
> such as pattern matching and multi-methods, but the syntax is still very
> simple. I'm familiar with Io, and I think the syntax is easy to learn,
Io was a big inspiration. That's the main reason Magpie doesn't use a
"." between receiver and method.
> and
> like you, I find Scala has too much syntax sugar - optional parenthesis,
> "word soup", as you put it, etc.
>
> I'll be reading a bit more and hopefully playing with it a bit (but
> Battlefield 3 comes first :)
I approve of that prioritization. :)
- bob