Programming racket like in guile

Programming racket like in guile

[stefan.itampe]

Dear guilers!

I have spend quite a lot of work porting racket code to guile
e.g. syntax-parse and the code for contracts, as a spinoff I have
done several other parts as well e.g.

* contracts                                (guile-contract)
* syntax parse                             (guile-syntax-parse)
* some support for racket lambda argumnets 
  lambda list                              (guile-syntax-parse)

* some support for racket structs          (guile-contract)
* racket matcher                           (guile-syntax-parse)
* racket for loops                         (racket-loops-for-guile)
* may things I have forgotten about

Is there something in here that you would like to improve on or are 
there 
components in the racket codebase that you would like to have in guile
so please let me know!

I also suggest that for people writing compatability code that we have
a standard namespace for this. Let me suggest

(compat name-of-scheme/lisp component ...)
e.g.
(compat racket match)
(compat racket for)
(compat racket struct)

The idea is that we push code here that is useful for porting
the components that we are actually interesting to have in guile
 like syntax-parse.

for the code that we deem so useful that we would like to push it to a 
more
descriptive location we will of cause do that as well e.g. (syntax 
parse)

WDYT

Cheers!
Stefan

Re: Programming racket like in guile

[Ludovic Courtès]

Hi!

stefan.itampe@gmail.com skribis:

> I have spend quite a lot of work porting racket code to guile
> e.g. syntax-parse and the code for contracts, as a spinoff I have
> done several other parts as well e.g.

Would you like to come up with individual commits to add those to Guile?

Ludo’.

Re: Programming racket like in guile

[stefan.itampe]

On Friday, February 22, 2013 04:56:24 PM Ludovic Courtès wrote:
> Hi!
> 
> stefan.itampe@gmail.com skribis:
> > I have spend quite a lot of work porting racket code to guile
> > e.g. syntax-parse and the code for contracts, as a spinoff I have
> > done several other parts as well e.g.
> 
> Would you like to come up with individual commits to add those to
> Guile?
> 
> Ludo’.

Please be clear to what you would like to include. I would order it
like this


1. misc small utilities used in the translation process. This can
probably be compartmentized more but it's kind of nice to have one
include file.

2. Syntax parse. I used syntax parse to make most of the more advanced
macros in the compability layer.

3. Racket For loops, used quite extensively in racket code

4. Racket Structs, also used quite a lot in racket code

5. Racket lambda utilities, used extensively in contract code

6. racket contracts,

7. racket match, A nice matcher that even has PEG qualities.

/Stefan

Re: Programming racket like in guile

[Daniel Hartwig]

On 22 February 2013 04:59,  <stefan.itampe@gmail.com> wrote:
> I also suggest that for people writing compatability code that we have
> a standard namespace for this. Let me suggest
>
> (compat name-of-scheme/lisp component ...)
> e.g.
> (compat racket match)
> (compat racket for)
> (compat racket struct)
>
> The idea is that we push code here that is useful for porting
> the components that we are actually interesting to have in guile
>  like syntax-parse.

For those parts specific to racket, did you consider the (language
racket ..) namespace, where an eventual language definition could be
placed also?

Re: Programming racket like in guile

[Ian Price]

Daniel Hartwig <mandyke@gmail.com> writes:

> For those parts specific to racket, did you consider the (language
> racket ..) namespace, where an eventual language definition could be
> placed also?

That sounds somewhat misleading, since Racket is not really one
language. Yeah, there is #lang racket, but they have others as well.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Programming racket like in guile

[Stefan Israelsson Tampe]

On Saturday, February 23, 2013 08:54:09 AM Daniel Hartwig wrote:
> For those parts specific to racket, did you consider the (language
> racket ..) namespace, where an eventual language definition could be
> placed also?

Hmm, my problem with this is that to cover the racket lang is a
monumental effort because it covers such things like imutable cons
cells a new macrology system, a new module system etc. It would take
me forever to actually complete anything close to #lang
racket. Therefore I prefere to call it a compatibility module. The
idea is to minimize the work needed to port code written in racket to
guile. If we than mange after some significant time to repreoduce
#:lan racket we can of cause promote this module to (language
racket). Does this make sense?

/Stefan

Re: Programming racket like in guile

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

That makes sense, but if the promotion ever happens, then there might be a
bunch of old code using (compat racket ...) that would need to be
converted, and we would have to keep the (compat racket ...) modules around
for compatibility with old code. If there's any possibility that we will
want to rename it to (language racket ...), I think we should do it right
now, in the beginning, so that users of those modules don't have to change.

It's fine for language support to be incomplete. That's how (language
ecmascript) is right now.

Best,
Noah



On Sat, Feb 23, 2013 at 7:44 AM, Stefan Israelsson Tampe <
stefan.itampe@gmail.com> wrote:

> On Saturday, February 23, 2013 08:54:09 AM Daniel Hartwig wrote:
> > For those parts specific to racket, did you consider the (language
> > racket ..) namespace, where an eventual language definition could be
> > placed also?
>
> Hmm, my problem with this is that to cover the racket lang is a
> monumental effort because it covers such things like imutable cons
> cells a new macrology system, a new module system etc. It would take
> me forever to actually complete anything close to #lang
> racket. Therefore I prefere to call it a compatibility module. The
> idea is to minimize the work needed to port code written in racket to
> guile. If we than mange after some significant time to repreoduce
> #:lan racket we can of cause promote this module to (language
> racket). Does this make sense?
>
> /Stefan
>
>
>

[-- Attachment #2: Type: text/html, Size: 2018 bytes --]

Re: Programming racket like in guile

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

Hello,

On Fri, Feb 22, 2013 at 9:32 PM, Ian Price <ianprice90@googlemail.com>wrote:

> Daniel Hartwig <mandyke@gmail.com> writes:
>
> > For those parts specific to racket, did you consider the (language
> > racket ..) namespace, where an eventual language definition could be
> > placed also?
>
> That sounds somewhat misleading, since Racket is not really one
> language. Yeah, there is #lang racket, but they have others as well.
>

It's true that racket is both a programming system for many languages and
the name of one specific language. I don't think it's too ambiguous to use
(language racket ...) for that one specific language. After all, if we
don't call it racket, then that language has no name!

Unless you want to use (language racket ...) for all of the things
supported by Racket, and maybe (language racket racket) for the actual
#lang racket language. It seems excessive to me, but I'm not completely
sure about that.

Best,
Noah

[-- Attachment #2: Type: text/html, Size: 1520 bytes --]

Re: Programming racket like in guile

[Stefan Israelsson Tampe]

Let me illustrate the problem.

Consider macro syntax-parse written in (language racket). My view is 
that the
sourcecode for that code should just have been copied from the racket
sources in order to keep the code maintainable. Could we use that
macro from whithin a guile scheme program? sometimes but for this 
example
the syntax-parse macro uses so many features in racket syntax expander
that you simply cannot use it without copying the racket macro
framework. So you have racket macros and you have guile macros and
they do not compose.

But we would like to be able to use syntax-parse in guile
scheme. Hence we must port over the code, and I can tell you that
porting syntax-parse is not trivial. Should we mix guile syntax parse
and racket syntax parse in the same namespace.

It is the same store when it comes to porting over common lisp
ideoms. If you would like to port cl's loop macro to guile you cannot
use the sources. The reason is that cl uses tagbody and tagbody is not
supported in tree-il. So you write a separate port in scheme with 
syntax-parse and friends and use that. On the other hand I had a
though of extending tree-il with a tagbody form and use that as a
separate language, again macros would not compose and the same issue
will appear. 

Say that we manage to unify the macrology, no problem, then we can
just use re-export.

Hope this show some light on the problem
/Stefan

Re: Programming racket like in guile

[Ludovic Courtès]

stefan.itampe@gmail.com skribis:

> 1. misc small utilities used in the translation process. This can
> probably be compartmentized more but it's kind of nice to have one
> include file.
>
> 2. Syntax parse. I used syntax parse to make most of the more advanced
> macros in the compability layer.
>
> 3. Racket For loops, used quite extensively in racket code
>
> 4. Racket Structs, also used quite a lot in racket code
>
> 5. Racket lambda utilities, used extensively in contract code
>
> 6. racket contracts,
>
> 7. racket match, A nice matcher that even has PEG qualities.

OK, I was hoping that things would be somewhat independent, but
apparently no.

What would have been nice IMO is to import, say, ‘syntax-parse’ and
contracts, without having to pull in a whole compatibility layer.

Ludo’.

Re: Programming racket like in guile

[Stefan Israelsson Tampe]

On Sunday, February 24, 2013 10:07:36 PM Ludovic Courtès wrote:
> What would have been nice IMO is to import, say, ‘syntax-parse’ and
> contracts, without having to pull in a whole compatibility layer.
> 
> Ludo’.

I would say that I tried more to make syntax-parse
independent. contracts on the other hand depends on syntax-parse for
loops racket structs etc. That said syntax parse is quite a hefty
sized library.

/Stefan