Re: [racket-users] Could Racket be used as a "frontend" for a non-Racket language?

[Philip McGrath]

I haven't done much with this personally, but a few pointers in Racket:

   - Urlang uses Racket's macro system as a front-end for JavaScript (in
   the way you discuss with C#, not compiling Racket to JavaScript):
   https://github.com/soegaard/urlang
   - Alexis King's Hackett is an experimental Haskell-like `#lang`:
   https://lexi-lambda.github.io/hackett/ While it currently only runs on
   the Racket runtime system, Alexis' blog post, "Reimplementing Hackett’s
   type language: expanding to custom core forms in Racket", discusses the
   possibility of an alternate backend targeting GHC and goes into extremely
   useful detail about implementation techniques that can help:
   
https://lexi-lambda.github.io/blog/2018/04/15/reimplementing-hackett-s-type-language-expanding-to-custom-core-forms-in-racket/
   - The recent paper "Macros for Domain-Specific Languages" (
   https://dl.acm.org/doi/pdf/10.1145/3428297) presents a high-level API
   for doing many of the things the aforementioned blog post implements by
   hand. (Alexis is a co-author on the paper.)  The `ee-lib` library provides
   the API discussed in the paper:
   https://docs.racket-lang.org/ee-lib/index.html (I have done the by-hand
   approach to custom core forms, and I'm excited to try the new library.)

-Philip


On Sun, Jun 6, 2021 at 11:35 PM Robert Calco  wrote:

> Check out IronScheme ... it may
> be just what you're looking for.
>
> - Bob
>
> On Sun, Jun 6, 2021 at 10:02 PM Ryan Kramer 
> wrote:
>
>> I have no plans to work on this, but I am curious if this has been
>> discussed or attempted...
>>
>> Motivation: My job has been C# for many years and while C# is very
>> appropriate for most of the problems I encounter at work, sometimes a
>> problem comes along that makes me want more power. In those situations, I
>> think the language I want is "C# except now it's S-expressions and it has
>> Racket's macro system."
>>
>> And then I wonder if an alternate version of C# could be implemented this
>> way:
>> 1) Create a new grammar for what a fully-expanded C# AST is. This will be
>> in terms of Racket syntax objects, just like Racket's definition of a Fully
>> Expanded Program.
>> 2) Write a compiler that generates CIL (the bytecode) given a
>> fully-expanded C# AST.
>> 3) Use Racket's #lang mechanism and macro system to implement the surface
>> language.
>>
>> Now this new C# could borrow a lot of power from Racket, right? For
>> example, I could make all of Racket available during expansion! Even if I
>> don't want C#-the-surface-language to have macros at all, why shouldn't I
>> keep the Racket-powered backdoor open? As long as you generate a valid C#
>> AST, I should be able to compile it for you.
>>
>> The #lang mechanism and Scribble are two other nice things that could
>> probably be adapted into the new C# if desired.
>>
>> I can understand why Microsoft wouldn't do this. But I've seen enough
>> hobby languages, and I'm surprised that none of them do this. Reusing a
>> backend (like dotnet or the JVM) is common, reusing a "frontend" is
>> something I've never seen. Is Racket's macro system too specific to
>> Racket's definition of a fully-expanded program? (The little bit I've done
>> with local-expand and stop-ids makes me think it would work fine.) Is there
>> something else that would make this approach more trouble than it's worth?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/cc7c1792-ba59-400f-856a-3bb02a6096fbn%40googlegroups.com
>> 
>> .
>>
>
>
> --
> *Bob Calco*
>
> bobca...@gmail.com
> 813-997-3583 (work mobile)
> 813-523-3751 (personal mobile)
>
> *"But you can catch yourself entertaining habitually certain ideas and
> setting others aside; and this, I think, is where our personal destinies
> are largely decided." *-- *Alfred North Whitehead*
>
> *"And now I see with eye serene the very pulse of the machine." *--* William
> Wordsworth*
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAATHPo3MJDtgxrt3FKPTRvt-avaniq4LTwF6VH_SSe%3DvAV3V4A%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google 

Re: [racket-users] Could Racket be used as a "frontend" for a non-Racket language?

[Robert Calco]

Check out IronScheme ... it may
be just what you're looking for.

- Bob

On Sun, Jun 6, 2021 at 10:02 PM Ryan Kramer 
wrote:

> I have no plans to work on this, but I am curious if this has been
> discussed or attempted...
>
> Motivation: My job has been C# for many years and while C# is very
> appropriate for most of the problems I encounter at work, sometimes a
> problem comes along that makes me want more power. In those situations, I
> think the language I want is "C# except now it's S-expressions and it has
> Racket's macro system."
>
> And then I wonder if an alternate version of C# could be implemented this
> way:
> 1) Create a new grammar for what a fully-expanded C# AST is. This will be
> in terms of Racket syntax objects, just like Racket's definition of a Fully
> Expanded Program.
> 2) Write a compiler that generates CIL (the bytecode) given a
> fully-expanded C# AST.
> 3) Use Racket's #lang mechanism and macro system to implement the surface
> language.
>
> Now this new C# could borrow a lot of power from Racket, right? For
> example, I could make all of Racket available during expansion! Even if I
> don't want C#-the-surface-language to have macros at all, why shouldn't I
> keep the Racket-powered backdoor open? As long as you generate a valid C#
> AST, I should be able to compile it for you.
>
> The #lang mechanism and Scribble are two other nice things that could
> probably be adapted into the new C# if desired.
>
> I can understand why Microsoft wouldn't do this. But I've seen enough
> hobby languages, and I'm surprised that none of them do this. Reusing a
> backend (like dotnet or the JVM) is common, reusing a "frontend" is
> something I've never seen. Is Racket's macro system too specific to
> Racket's definition of a fully-expanded program? (The little bit I've done
> with local-expand and stop-ids makes me think it would work fine.) Is there
> something else that would make this approach more trouble than it's worth?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/cc7c1792-ba59-400f-856a-3bb02a6096fbn%40googlegroups.com
> 
> .
>


-- 
*Bob Calco*

bobca...@gmail.com
813-997-3583 (work mobile)
813-523-3751 (personal mobile)

*"But you can catch yourself entertaining habitually certain ideas and
setting others aside; and this, I think, is where our personal destinies
are largely decided." *-- *Alfred North Whitehead*

*"And now I see with eye serene the very pulse of the machine." *--* William
Wordsworth*

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAATHPo3MJDtgxrt3FKPTRvt-avaniq4LTwF6VH_SSe%3DvAV3V4A%40mail.gmail.com.

Re: [racket-users] Could Racket be used as a "frontend" for a non-Racket language?

[Raoul Duke]

nice, yes, I've long wanted that, in general. Like, I want to use
{erlang,ADA,haskell,typescript,go,...} but with s-expr's and macros.

One could instead perhaps leverage Graal and things like ABCL or
Clojure? You could in theory use something like XMLVM and Clojure to
at least cover C#/.net and Java. (because another layer of indirection
in a programming tool chain is never a problem, nope.) Or one could
perhaps make a gcc s-expr front end https://superuser.com/a/1198792
and somehow leverage gcc's RTL to intermix-ffi with other languages?
no idea. in this day and age i guess llvm is better? i'm a static
typing lover, and some of the languages I'd like to see targeted are
statically typed, so ideally it would be maybe something like TR
supporting the target language type system, which probably is too much
like square peg round hole -> unless one falls back to Xtend-esque
approach which would compile to source code in Java/C# and then use
the "native" compiler to type check.

???

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAJ7XQb6mJRtEeCEzk54rK8cQt2cTuregSGWg7Tfh4kLQQqcO4Q%40mail.gmail.com.

[racket-users] Could Racket be used as a "frontend" for a non-Racket language?

[Ryan Kramer]

I have no plans to work on this, but I am curious if this has been 
discussed or attempted...

Motivation: My job has been C# for many years and while C# is very 
appropriate for most of the problems I encounter at work, sometimes a 
problem comes along that makes me want more power. In those situations, I 
think the language I want is "C# except now it's S-expressions and it has 
Racket's macro system."

And then I wonder if an alternate version of C# could be implemented this 
way:
1) Create a new grammar for what a fully-expanded C# AST is. This will be 
in terms of Racket syntax objects, just like Racket's definition of a Fully 
Expanded Program.
2) Write a compiler that generates CIL (the bytecode) given a 
fully-expanded C# AST.
3) Use Racket's #lang mechanism and macro system to implement the surface 
language.

Now this new C# could borrow a lot of power from Racket, right? For 
example, I could make all of Racket available during expansion! Even if I 
don't want C#-the-surface-language to have macros at all, why shouldn't I 
keep the Racket-powered backdoor open? As long as you generate a valid C# 
AST, I should be able to compile it for you.

The #lang mechanism and Scribble are two other nice things that could 
probably be adapted into the new C# if desired.

I can understand why Microsoft wouldn't do this. But I've seen enough hobby 
languages, and I'm surprised that none of them do this. Reusing a backend 
(like dotnet or the JVM) is common, reusing a "frontend" is something I've 
never seen. Is Racket's macro system too specific to Racket's definition of 
a fully-expanded program? (The little bit I've done with local-expand and 
stop-ids makes me think it would work fine.) Is there something else that 
would make this approach more trouble than it's worth?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/cc7c1792-ba59-400f-856a-3bb02a6096fbn%40googlegroups.com.

Re: [racket-users] Can a new user defined pkg encompass nothing more than references to previously defined pkgs?

[Philip McGrath]

On Sun, Jun 6, 2021 at 7:59 PM Ben Greenman 
wrote:

> On 6/6/21, Don Green  wrote:
> >
> > Can a new user defined pkg encompass nothing more than references to
> > previously defined pkgs so that every  user created module references a
> > single user defined pkg?
>
> Yes. You can make a new package whose main.rkt provides lots of
> identifiers from other packages.


I can see at least three different interpretations of the question. In an
attempt to clear up any possible misunderstandings, let me try to pull them
apart:

   1. Ben's answer is correct if the question really meant, "so that every
   user created module references a single user defined" *module*. The
   omnibus module (`#lang reprovide` is a good choice) may be in the same
   package as other user-defined modules that use it, or additional packages
   may depend on the package containing the omnibus module.
   2. If the question instead meant, "so that every user created" *package*
   "references a single user defined pkg", the answer is also yes, but in a
   different way. A good example of this would be the "typed-racket" package,
   which combines the packages "typed-racket-lib" and "typed-racket-doc". The
   "typed-racket" consists simply of an "info.rkt" file with appropriate
   definitions for `deps` and `implies`.
   3. On the other hand, if the question literally meant, "so that every
   user created module references a single user defined pkg", then the answer,
   strictly speaking, is no, because modules can not refer to packages per se.

The third possibility is where I see the most potential for
misunderstanding. From Package Management in Racket", § 1.1 "What is a
Package?" <
https://docs.racket-lang.org/pkg/getting-started.html#%28part._.What_is_a_.Package_%29
>:

> A package
> 
> is not something that you refer to directly in your Racket programs.
> Instead, a package
> 
> is a set of libraries that fit into the collection
> 
> hierarchy, and you refer to libraries through their collection
> -based
> paths. Libraries that are close in the hierarchy may be provided by
> different packages, while a single package may provide libraries that are
> far from each other in the hierarchy (but that are conceptually related,
> somehow).
>
> Racket documentation tells you which package provides a given library. For
> example, the documentation for the pict/face
> 
> library says that it is provided by the pict-lib package.If you’re
> reading this in a web browser, click pict/face
> 
> to go straight to its documentation.
>
> Over time, packages may be refactored so that a library moves to a
> different package, but the original package should continue to provide the
> library, too, by declaring a dependency on the new package. More generally,
> a package is intended to have an interface that only grows in terms of
> libraries, bindings, and functionality, which provides a basic level of
> backward compatibility. Incompatible changes should be implemented in a new
> package.
>

-Philip

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/01000179e4110586-44232b9f-4563-478e-b00a-6b909a341c13-00%40email.amazonses.com.

Re: [racket-users] Can a new user defined pkg encompass nothing more than references to previously defined pkgs?

[Ben Greenman]

On 6/6/21, Don Green  wrote:
>
> Can a new user defined pkg encompass nothing more than references to
> previously defined pkgs so that every  user created module references a
> single user defined pkg?

Yes. You can make a new package whose main.rkt provides lots of
identifiers from other packages.

`#lang reprovide` is a nice way to get this done:

  https://docs.racket-lang.org/reprovide/index.html

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAFUu9R6_--DsiZY49BN5W8Mchs5WEXcfDk8DrsP1DwTXketMNg%40mail.gmail.com.

[racket-users] Can a new user defined pkg encompass nothing more than references to previously defined pkgs?

[Don Green]

Can a new user defined pkg encompass nothing more than references to 
previously defined pkgs so that every  user created module references a 
single user defined pkg?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/e13fc410-8d3d-4ec0-a811-20b94832ad0bn%40googlegroups.com.

[racket-users] Re: Embedded Racket reimplementation for constrained hardware?

[schle...@gmail.com]

I think in such an environment I would like to control memory usage myself, 
or maybe have a #lang that allows very fine grained and low level control 
over resources. (outputting lowerlevel code than racket/base). 
If you need persistent data-structures they are nice, but often times you 
don't need them. 
Basically I would use a smaller language and build only the things I really 
need, instead of starting with racket and stripping away everything I don't 
need. 
(although if you manage to create a tool that accomplishes this in a very 
radical manner that could be cool as well, I just don't think that is easy)

That would boil down to partially evaluating racket specializing it to the 
target program, I don't think tools like `raco exe`, `raco distribute` etc. 
go so far that they would try to eliminate
base language features, which probably aren't "unused" anyway in any 
reasonably complex program.

Said another way: I think in a lot of cases it is easier to start creating 
a program with a language with less features, than trying to get rid of 
certain features after the program was already written using these 
features. If you start out without the features it is easier to reason 
about what features are worth implementing, for the particular program and 
what is over-engineered for the use-case.
That is just my perspective, I think there are many approaches to this, 
depending on the circumstances and concrete goals.

Simon

gneuner2 schrieb am Samstag, 5. Juni 2021 um 19:13:21 UTC+2:

> On Sat, 5 Jun 2021 06:45:44 -0700 (PDT), dbohdan
>  wrote:
>
> >Has anyone tried making a small embedded implementation of Racket? I mean 
> >"embedded" not in the sense of 8-bit microcontrollers but more powerful 
> yet 
> >still constrained devices, like routers with 64 MB RAM running Linux or 
> the 
> >PlayStation 2. I think you don't have to work from scratch to make one. 
> >You can implement Racket on top of an embedded Scheme like Chibi-Scheme 
> >. It doesn't need to be a full, 
> >maximally compatible port of Racket like Racket CS, just a large subset. 
> >For example, you can skip futures and places.
> >
> >What features do you need to implement natively in the interpreter rather 
> >than in Scheme? You can implement delimited continuations in terms of 
> >call/cc. The concurrency primitives (threads, boxes, etc.) and the FFI? 
> >You may be able to, but don't have to, optimize the interpreter for 
> >immutable conses.
> >
> >This is just something I have been musing about. If no project like this 
> >exists, I am not starting one soon.
>
> Racket can run in less than 64MB, but severely limited memory
> typically results in a lot of GC churn.
>
> George
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5d5f3114-ddaa-4e4b-af6b-e7f82a2fc670n%40googlegroups.com.

Re: [racket-users] Re: config.rktd

[Matthew Flatt]

At Fri, 4 Jun 2021 14:29:29 -0700 (PDT), Don Green wrote:
> Now that I have learned of: config.rktd,
> I think I'd rather use it, if it can be used to set 
> current-library-collection paths.
> Should I just add to the config.rktd hash list:
>  (current-library-collection paths . 
> '(# 
> # #)) 

To go this route, you will want something like

 (collects-search-dirs . ("/home/don/.plt-scheme/4.2.1/collects" #f))
 
That is, the syntax is the configuration key `collects-search-dirs`,
and the paths have to be in string form. A `#f` means "default paths
here".

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20210606064404.3b0%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] This v 8.1 collection path looks incorrect...

[Matthew Flatt]

At Fri, 4 Jun 2021 14:46:00 -0700 (PDT), Don Green wrote:
> 
> (current-library-collection-paths)
> '(# 
> # #)
> 
> I suspect the above is incorrect because I think the 8.1 path should be to 
> dir: /pkgs rather than /collects.  Like this:
> #

Just to clarify, "collects" is as intended there. Packages are found
via `current-library-collection-links` (although, as I mentioned in the
other reply, that's not a parameter that you normally need to set).

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20210606064032.294%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Regarding collections ...

[Matthew Flatt]

At Fri, 4 Jun 2021 14:15:11 -0700 (PDT), Don Green wrote:
> Sounds like ideally I should begin creating my own pkg(s) that are
> outside a collection path, and link it by specifying a
> current-library-collection-links parameter.

Yes, you should use packages. You normally shouldn't need to set the
`current-library-collection-links` parameter, though. Installing a
package will add to the links that are read via
`current-library-collection-links`

> In the mean time I'd like to add the collection path.
> ---
> Currently,
> When I open DrRacket and run: (current-library-collection-paths) it returns:
> '(# 
> # #) 
> which is correct and no problems, however
> when I click on a .ss file in the file-manager, the file is opened in 
> drracket v.8.1 but
> (current-library-collection-paths) returns only:
> '(# #)

This is really a question about how your OS deals with environment
variables and programs that you launch through its graphical interface.
It looks like you're on a Unix-like platform; unfortunately, I don't
know how quite things will work there.

> Is there a more convenient method to achieve what I am after by making some 
> configuration in racket rather than in my file-manager?

Although it's not the way Racket programmers normally work, there is an
option within DrRacket's GUI:

Open the "Choose Language..." dialog from the "Language" menu, then
select "Show Details". There's a configuration panel roughly in the
middle of the right-hand side for adding collects paths.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20210606063926.26%40sirmail.smtps.cs.utah.edu.