PEGification, the DLR

[Max Battcher-2]

I'm debating using Boo as a DSL prototyping tool if not the underlying
base of the full project.  (Boo seems to be about 80% of what I need,
perhaps.)  Here are a couple of questions that have been floating in
my head:

* How's progress on the Boo PEGification?  Is there an ETA yet?

* How much thought has been put into DLR integration?

Boo and the DLR (the Dynamic Language Runtime out of IronPython's team
for cross-dynamic language interaction/integration) have some similar
components and I think a standardization on the integrated DLR seems
like a perfect fit for Boo.  (The DLR "shared" AST seems reasonably
similar to parts of the Boo AST, at least to my very quick skimming of
both, and the DLR dynamic object interface is somewhat similar to
IQuackFu...)

Regards,

--
--Max Battcher--
http://www.worldmaker.net/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang
-~----------~----~----~----~------~----~------~--~---

[Ayende Rahien-2]

All AST will look very similar.
Take a look at CodeDOM as an example.

I don't see a value in DLR integration, we can do whatever we need to do on directly on the CLR.

On Thu, Jul 3, 2008 at 7:48 AM, Max Battcher <max.battcher@...> wrote:

I'm debating using Boo as a DSL prototyping tool if not the underlying
base of the full project.  (Boo seems to be about 80% of what I need,
perhaps.)  Here are a couple of questions that have been floating in
my head:

* How's progress on the Boo PEGification?  Is there an ETA yet?

* How much thought has been put into DLR integration?

Boo and the DLR (the Dynamic Language Runtime out of IronPython's team
for cross-dynamic language interaction/integration) have some similar
components and I think a standardization on the integrated DLR seems
like a perfect fit for Boo.  (The DLR "shared" AST seems reasonably
similar to parts of the Boo AST, at least to my very quick skimming of
both, and the DLR dynamic object interface is somewhat similar to
IQuackFu...)

Regards,

--
--Max Battcher--
http://www.worldmaker.net/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang
-~----------~----~----~----~------~----~------~--~---

[Max Battcher-2]

On Jul 3, 1:33 am, "Ayende Rahien" <aye...@...> wrote:
> All AST will look very similar.
> Take a look at CodeDOM as an example.

Yes, I know, but whereas CodeDOM offers very few ways to cut down on
code reuse (as it was intended primarily for documentation and
templates), the DLR AST is specifically built so that dynamic
languages can take advantage of it for passing dynamic code amongst
each other.  It seems to me that figuring out how to inter-operate/
merge the Boo AST with the DLR AST could provide some cool
interactions.

> I don't see a value in DLR integration, we can do whatever we need to do on
> directly on the CLR.

It's not a one or the other thing, and its not exactly an
"indirection".  In fact, you gain the benefit of Microsoft's own
attempts to best enhance the speed of things like dynamic function
calls and dynamic object member lookup.

You don't think it would be nice to be able to pass duck/dynamic
objects or anonymous/lambda functions to or from IronPython, IronRuby,
or Dynamic JScript, or any other DLR-based or DLR-integrated
language?   The DLR is meant to do for dynamic object systems like
Boo's Duck, Python, Ruby what the CLR does for static object systems
like C#.  Boo already straddles the static/dynamic fence and I think
DLR support would further enhance Boo's dynamic capabilities.

--
--Max Battcher--
http://www.worldmaker.net/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang
-~----------~----~----~----~------~----~------~--~---

[Justin Chase-2]

Hi Max,
  This sounds correct intuitively though I'm no expert on the DLR by any stretch. I'm just curious how you know so much about the DLR?

On Thu, Jul 3, 2008 at 3:03 AM, Max Battcher <max.battcher@...> wrote:

On Jul 3, 1:33 am, "Ayende Rahien" <aye...@...> wrote:
> All AST will look very similar.
> Take a look at CodeDOM as an example.

Yes, I know, but whereas CodeDOM offers very few ways to cut down on
code reuse (as it was intended primarily for documentation and
templates), the DLR AST is specifically built so that dynamic
languages can take advantage of it for passing dynamic code amongst
each other.  It seems to me that figuring out how to inter-operate/
merge the Boo AST with the DLR AST could provide some cool
interactions.

> I don't see a value in DLR integration, we can do whatever we need to do on
> directly on the CLR.

It's not a one or the other thing, and its not exactly an
"indirection".  In fact, you gain the benefit of Microsoft's own
attempts to best enhance the speed of things like dynamic function
calls and dynamic object member lookup.

You don't think it would be nice to be able to pass duck/dynamic
objects or anonymous/lambda functions to or from IronPython, IronRuby,
or Dynamic JScript, or any other DLR-based or DLR-integrated
language?   The DLR is meant to do for dynamic object systems like
Boo's Duck, Python, Ruby what the CLR does for static object systems
like C#.  Boo already straddles the static/dynamic fence and I think
DLR support would further enhance Boo's dynamic capabilities.

--
--Max Battcher--
http://www.worldmaker.net/

--
Justin Chase
http://www.justnbusiness.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang
-~----------~----~----~----~------~----~------~--~---

[gregcnagel]

The DLR discussion came up in the Boo IRC channel not too long ago.
http://servlet.uwyn.com/drone/log/hausbot/boo/20080627 Here's a
relevant excerpt.

21:17
<pfox>
basically all it is a collection of classes that make up an
infrastructure for hosting a language
21:17
<pfox>
but you're not really hosting it in the CLR, you're hosting it *on top
of* the DLR
21:17
<hangar>
maybe IQuackFu could be redone in the DLR for better interoperation
with other languages?
21:18
<pfox>
so calling into CLR objects is actually a chore, and objects/types/
variables etc in your language aren't CLR objects/types/variables,
they're part of your language
21:18
<pfox>
and you have to use a dispatch site to call into the CLR

I don't know much about the DLR, but from the discussion, what I
understand is that Boo wouldn't gain anything. The DLR is optimized to
compile code dynamically in a form specifically optimized to do that
at runtime. DLR languages aren't compiled down to CIL like Boo code
is, so including the DLR provides no benefit. Being able to share code
with DLR languages might be cool, but that would be like adding a
layer to C# to be able to talk to DLR code. Boo should just do what C#
does.

As for the PEG grammar, I know even less.

My advice: Don't rely on timelines for promised functionality in any
open source project, since you aren't paying to make sure it gets
done. Boo is a great language as it is now, already in use in several
DSLs. It can probably do what you want.

On Jul 3, 6:05 am, "Justin Chase" <justin.m.ch...@...> wrote:

> Hi Max,
>   This sounds correct intuitively though I'm no expert on the DLR by any
> stretch. I'm just curious how you know so much about the DLR?
>
>
>
>
>
> On Thu, Jul 3, 2008 at 3:03 AM, Max Battcher <max.battc...@...> wrote:
>
> > On Jul 3, 1:33 am, "Ayende Rahien" <aye...@...> wrote:
> > > All AST will look very similar.
> > > Take a look at CodeDOM as an example.
>
> > Yes, I know, but whereas CodeDOM offers very few ways to cut down on
> > code reuse (as it was intended primarily for documentation and
> > templates), the DLR AST is specifically built so that dynamic
> > languages can take advantage of it for passing dynamic code amongst
> > each other.  It seems to me that figuring out how to inter-operate/
> > merge the Boo AST with the DLR AST could provide some cool
> > interactions.
>
> > > I don't see a value in DLR integration, we can do whatever we need to do
> > on
> > > directly on the CLR.
>
> > It's not a one or the other thing, and its not exactly an
> > "indirection".  In fact, you gain the benefit of Microsoft's own
> > attempts to best enhance the speed of things like dynamic function
> > calls and dynamic object member lookup.
>
> > You don't think it would be nice to be able to pass duck/dynamic
> > objects or anonymous/lambda functions to or from IronPython, IronRuby,
> > or Dynamic JScript, or any other DLR-based or DLR-integrated
> > language?   The DLR is meant to do for dynamic object systems like
> > Boo's Duck, Python, Ruby what the CLR does for static object systems
> > like C#.  Boo already straddles the static/dynamic fence and I think
> > DLR support would further enhance Boo's dynamic capabilities.
>
> > --
> > --Max Battcher--
> >http://www.worldmaker.net/
>
> --
> Justin Chasehttp://www.justnbusiness.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang
-~----------~----~----~----~------~----~------~--~---

[Max Battcher-2]

On Jul 3, 9:05 am, "Justin Chase" <justin.m.ch...@...> wrote:
> Hi Max,
>   This sounds correct intuitively though I'm no expert on the DLR by any
> stretch. I'm just curious how you know so much about the DLR?

Short answer: Blog reading, mostly.

Long answer: I've spent much more time at this point in my DSL project
thinking about how best to implement rather than actually implementing
it.  At first I was considering building it entirely on top of the
DLR: the toy language included as an example with the DLR makes it
look really easy and the DLR throws in some nice pieces of the
Compiler/Interpreter stack for free as well.  But I had in mind
something "vaguely python like" and that seems to balloon
automatically in my head to "well, if it's vaguely python like it
should have lists and dicts and slicing... and list comprehensions and
generators and closures might be nice, too".  That has lead me to the
problem that I wouldn't mind an existing parser to hack onto if I'm
going to go "python-like"...  While I had no problems potentially
using or copying small sub parts of IronPython, most of which seemed
rather straightforward, I certainly don't want to hack on the
IronPython parser (after all it is *meant* to be as ugly as
CPython's).  From there that led me to PyPy (somewhat nicer Python
parser, but just as much subtle baroque-ness in order to emulate
CPython better; plus their CLR integration isn't entirely perfected
yet it appears, at least in the documentation) and then I was reminded
about Boo and its syntactic macros...  (So now I'm trying to see how
much of what I want to do I might be able to do entirely with Boo, and
if I end up hacking apart some Parser even the ANTLR Boo grammar seems
the kindest "python-like" one I've seen.)

--
--Max Battcher--
http://www.worldmaker.net/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang
-~----------~----~----~----~------~----~------~--~---

[Max Battcher-2]

On Jul 3, 2:20 pm, hangar <NagelBa...@...> wrote:

> The DLR discussion came up in the Boo IRC channel not too long ago.http://servlet.uwyn.com/drone/log/hausbot/boo/20080627Here's a
> relevant excerpt.
>
> 21:17
> <pfox>
> basically all it is a collection of classes that make up an
> infrastructure for hosting a language
> 21:17
> <pfox>
> but you're not really hosting it in the CLR, you're hosting it *on top
> of* the DLR
> 21:17
> <hangar>
> maybe IQuackFu could be redone in the DLR for better interoperation
> with other languages?
> 21:18
> <pfox>
> so calling into CLR objects is actually a chore, and objects/types/
> variables etc in your language aren't CLR objects/types/variables,
> they're part of your language
> 21:18
> <pfox>
> and you have to use a dispatch site to call into the CLR

pfox sounds entirely wrong.  To the best of my knowledge, dispatch
sites are part of the Dynamic call optimization and are not used in
between "normal" CLR calls...  A language is still interacting as much
if not more with the CLR "in the usual ways" as it deals with the
DLR.  The DLR, despite the name is much closer to a friendly library
full of features than a "replacement" for CLR support.

http://blogs.msdn.com/mmaly/archive/2008/01/22/building-a-dlr-language-dynamic-behaviors-3.aspx

> I don't know much about the DLR, but from the discussion, what I
> understand is that Boo wouldn't gain anything.

From my understanding all lookups and calls to members on duck-like
objects from Boo get potentially optimized, and at the very least
become "shareable"...

> The DLR is optimized to
> compile code dynamically in a form specifically optimized to do that
> at runtime.

No, Dynamic != Runtime.

> DLR languages aren't compiled down to CIL like Boo code
> is, so including the DLR provides no benefit.

DLR languages are compiled to CIL.  Generally this is a "Just-in-time
compilation compilation" sort of thing, but you can get IronPython to
output an assembly similar to the way Boo does:

http://lists.ironpython.com/pipermail/users-ironpython.com/2006-June/002537.html

It's just not fully encouraged because that's not how the CPython
world operates and IronPython's first job is to be a good CPython
emulator.

> Being able to share code
> with DLR languages might be cool, but that would be like adding a
> layer to C# to be able to talk to DLR code. Boo should just do what C#
> does.

C# ("version 4.0") and VB.NET ("version 10.0") will both be getting
DLR-integration.

"VBx" will have DLR integration very similar to VB's historical
balance between static typing and dynamic typing (that ultimately is
rather similar to Boo's balance between static typing and dynamic
typing)...

http://blogs.msdn.com/vbteam/archive/2007/06/07/what-is-the-difference-between-vb-9-vbx-and-silverlight.aspx

On the other hand, the C# time, last I heard, is still trying to find
a preferred syntax for the static to dynamic cross-over.  Here's the
proposed syntax that I've seen:

http://blogs.msdn.com/srivatsn/archive/2008/02/05/dynamic-dispatch-in-c.aspx

> My advice: Don't rely on timelines for promised functionality in any
> open source project, since you aren't paying to make sure it gets
> done. Boo is a great language as it is now, already in use in several
> DSLs. It can probably do what you want.

Yes, I know that.  That's common sense.  I also know that even in open
source projects sometimes developers work in "silent parallel" mode
and forget to chime in with code merges and status updates if the
community fails to ask about them, thus my gentle inquiry into the
status of the project.

--
--Max Battcher--
http://www.worldmaker.net/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang
-~----------~----~----~----~------~----~------~--~---