Discussion:
[ragel-users] additional plans for 7.0
Adrian Thurston
2013-03-06 02:44:31 UTC
Permalink
Ragel 7 includes a new implementation of conditions. This has
necessitated major changes to the code generators.

While I'm at it, I'm want to take a new approach to code generation. The
plan is to generate an intermediate language, then transform that to the
various languages that ragel supports.

The transformation will be implemented in Colm.

http://www.complang.org/colm/

-Adrian
ragel-user
2013-03-06 16:02:12 UTC
Permalink
Do you plan to use an intermediate language that is already available? E.g.
s.th. like CIL:
http://www.ecma-international.org/publications/standards/Ecma-335.htm)?

jg
Adrian Thurston
2013-03-08 03:26:43 UTC
Permalink
At this point I'm not sure. The intermediate language would need common
high-level constructs such as if blocks, while loops, arrays, etc. CIL
seems to be targeted at machine code.

On 13-03-06 11:02 AM, ragel-user at jgoettgens.de wrote:
> Do you plan to use an intermediate language that is already available?
> E.g. s.th. like CIL:
> http://www.ecma-international.org/publications/standards/Ecma-335.htm)
>
> jg
>
> _______________________________________________
> ragel-users mailing list
> ragel-users at complang.org
> http://www.complang.org/mailman/listinfo/ragel-users
ragel-user
2013-03-08 11:21:50 UTC
Permalink
Yes, but does it hurt? My understanding is that you are using a
transformation tool anyway. Personally I would say that a lower level
description is a perfect match for an FSM, which would also give you more
freedom to implement the characterics of a higher level language. If the
intermediate language is already at a fairly high level, anything derived
from that probably soon faces the problem of the lowest common denominator.

There are decompilers available for CIL that typically generate C# code. As
a start, one could look at them to see how they deal with the code
generation.

I have not looked at Colm yet, but some time ago I played with txl. Txl
seems to be more suitable for text based transformations. Working with CIL
probably asks for implementing sequences of tree transformations at a binary
level until you arrive at something that can easily be printed out as native
source code.

This way one could easily support native looking C++, Lisp, or FORTRAN 77
(not really). CIL byte code is more or less language independent.

I would have a personal interest in this kind of low level stuff, so I could
contribute more than usual.

jg
Adrian Thurston
2013-03-09 15:30:37 UTC
Permalink
If the intermediate language doesn't have high-level constructs then
we're going to be compiling them out, only to have to bring them back
for the transformation to the target languages (C, Java, Ruby, etc).
That strikes me as the wrong approach.

On 13-03-08 06:21 AM, ragel-user at jgoettgens.de wrote:
> Yes, but does it hurt? My understanding is that you are using a
> transformation tool anyway. Personally I would say that a lower level
> description is a perfect match for an FSM, which would also give you
> more freedom to implement the characterics of a higher level language.
> If the intermediate language is already at a fairly high level, anything
> derived from that probably soon faces the problem of the lowest common
> denominator.
>
> There are decompilers available for CIL that typically generate C# code.
> As a start, one could look at them to see how they deal with the code
> generation.
>
> I have not looked at Colm yet, but some time ago I played with txl. Txl
> seems to be more suitable for text based transformations. Working with
> CIL probably asks for implementing sequences of tree transformations at
> a binary level until you arrive at something that can easily be printed
> out as native source code.
>
> This way one could easily support native looking C++, Lisp, or FORTRAN
> 77 (not really). CIL byte code is more or less language independent.
>
> I would have a personal interest in this kind of low level stuff, so I
> could contribute more than usual.
>
> jg
>
>
> _______________________________________________
> ragel-users mailing list
> ragel-users at complang.org
> http://www.complang.org/mailman/listinfo/ragel-users
ragel-user
2013-03-09 21:13:10 UTC
Permalink
I see your point. I'd tend to think that the source code is unlikely to look
like human written code anyway. So why not use to s.th that is closer to the
machine (20 different branch instructions may even look cool). In a way one
would always have to think in terms of s.th like an assembler language and
the translations to a higher level language would be for practical purposes
only.

Do you have s.th. like the following in mind? An abstract loop declaration
could be mapped in C++ either to individual statements or s.th. that uses an
STL algorithm (e.g. for_each). In a way there would be a bunch of higher
level building blocks, maybe sometimes with more than 1 option for a single
language. So the intermediate language would specify the algorithm
essentially in terms of these building blocks.

jg
Benjamin van der Veen
2013-03-09 22:49:46 UTC
Permalink
On Mar 9, 2013, at 13:13, <ragel-user at jgoettgens.de> wrote:

> s.th

Pardon my ignorance, but what is s.th? It's a bit tough to Google. ;)
Dan Kortschak
2013-03-09 23:10:40 UTC
Permalink
My guess: "some thing"

>> Pardon my ignorance, but what is s.th? It's a bit tough to Google. ;)
Pazzo Da Legare
2013-03-06 20:42:41 UTC
Permalink
Thank you Adrian for your wonderful work!
pz


Il giorno mercoled? 6 marzo 2013, Adrian Thurston ha scritto:

> Ragel 7 includes a new implementation of conditions. This has necessitated
> major changes to the code generators.
>
> While I'm at it, I'm want to take a new approach to code generation. The
> plan is to generate an intermediate language, then transform that to the
> various languages that ragel supports.
>
> The transformation will be implemented in Colm.
>
> http://www.complang.org/colm/
>
> -Adrian
>
> ______________________________**_________________
> ragel-users mailing list
> ragel-users at complang.org
> http://www.complang.org/**mailman/listinfo/ragel-users<http://www.complang.org/mailman/listinfo/ragel-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.complang.org/pipermail/ragel-users/attachments/20130306/684e8cea/attachment.html>
Anton Ageev
2013-03-09 16:25:41 UTC
Permalink
On Wed, Mar 6, 2013 at 6:44 AM, Adrian Thurston <thurston at complang.org>wrote:

> The transformation will be implemented in Colm.
>
> http://www.complang.org/colm/
>

Any plans for Colm manual?

--
WBR, Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.complang.org/pipermail/ragel-users/attachments/20130309/da3cc455/attachment.html>
Adrian Thurston
2013-03-09 16:28:38 UTC
Permalink
Plans, yes :) I can't say exactly when it will happen though. Right now
I'm giving it a self-hosted grammar. After that I want to make a few
tweaks to the language, then documentation will be next.

On 13-03-09 11:25 AM, Anton Ageev wrote:
> On Wed, Mar 6, 2013 at 6:44 AM, Adrian Thurston <thurston at complang.org
> <mailto:thurston at complang.org>> wrote:
>
> The transformation will be implemented in Colm.
>
> http://www.complang.org/colm/
>
>
> Any plans for Colm manual?
>
> --
> WBR, Anton
>
>
> _______________________________________________
> ragel-users mailing list
> ragel-users at complang.org
> http://www.complang.org/mailman/listinfo/ragel-users
>
Adrian Thurston
2013-03-10 00:39:33 UTC
Permalink
You got it. Write out ragel implementations in some generic algol-like language, then translate that to the various languages that ragel supports. The coder writing the translator does not need to understand ragel semantics in depth, only the mapping from the intermediate language to the target language.

Adrian
------Original Message------
From: ragel-user at jgoettgens.de
Sender: ragel-users-bounces at complang.org
To: ragel-users
ReplyTo: ragel-users
Subject: Re: [ragel-users] additional plans for 7.0
Sent: Mar 9, 2013 4:13 PM

I see your point. I'd tend to think that the source code is unlikely to look
like human written code anyway. So why not use to s.th that is closer to the
machine (20 different branch instructions may even look cool). In a way one
would always have to think in terms of s.th like an assembler language and
the translations to a higher level language would be for practical purposes
only.

Do you have s.th. like the following in mind? An abstract loop declaration
could be mapped in C++ either to individual statements or s.th. that uses an
STL algorithm (e.g. for_each). In a way there would be a bunch of higher
level building blocks, maybe sometimes with more than 1 option for a single
language. So the intermediate language would specify the algorithm
essentially in terms of these building blocks.

jg
ragel-user
2013-03-10 14:07:26 UTC
Permalink
Adrian, what would you be offering to a language implementer? I'd prefer an
AST for simplicity :), but I fear you would prefer the intermediate plain
text language only. Implementers are then supposed to use a tool like txl
(or colm) to generate their target language.

jg
Adrian Thurston
2013-03-10 14:23:25 UTC
Permalink
Colm can generate a C++ interface to the input grammar. You can either
use the Colm transformation language or write C++ code that traverses
the intermediate language parse tree.

On 13-03-10 10:07 AM, ragel-user at jgoettgens.de wrote:
> Adrian, what would you be offering to a language implementer? I'd prefer
> an AST for simplicity :), but I fear you would prefer the intermediate
> plain text language only. Implementers are then supposed to use a tool
> like txl (or colm) to generate their target language.
>
> jg
Loading...