Re: [racket-users] Multiple namespaces in Racket

[Alexis King]

> On Oct 13, 2017, at 18:52, Geoffrey Knauth  wrote:
> 
> Maybe do undisputedly?-evil name-mangling now to get things working,
> then become a saint with a better solution down the road.  Sometimes
> I don't realize how to do something the "good" way until I've traveled
> down the path of doing it some less than good way, then the "good" way
> reveals itself early one morning or late one night, when I least
> expect it.  30 years ago C++ had ugly name mangling, until that ugly
> part of C++ went away 5-10 years later.  The non-mangling way did not
> reveal itself at first.

I decided to take your advice and give this a try. I came up with a
solution using name mangling that seems to work at first blush, though
I’ve only thrown an extremely simple problem at it. The example and its
implementation are available here:

  https://gist.github.com/lexi-lambda/dbd9371f1268f72f9a0b9f8e09e1b46c

I’m not sure if this technique will hold up under additional stress, but
it seems to work alright, so I’m going to try applying it to Hackett
itself.

Additionally, in the process of creating this example, I discovered that
the documentation for splicing-syntax-parameterize appears to be a lie:
splicing-syntax-parameterize works quite well with require transformers.
Perhaps that caveat no longer applies with the set-of-scopes expander?
I hope I’m not relying on intentionally undefined behavior.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: [ANN] Porting PAIP's Prolog interpreter from Common Lisp to Racket, 1st version

[Luis Marcelo Rosso]

What a pity to live so far away (Buenos Aires, Argentina) from such 
interesting events...

But at least I would have the chance to watch the livestreams ! Thanks for 
sharing them !

El sábado, 14 de octubre de 2017, 3:23:15 (UTC-3), Jack Firth escribió:
>
> This is really cool, thanks for writing about it and sharing it! And 
> thanks for showing me another book I ought to get around to reading.
>
> There were some very interesting talks last weekend at RacketCon 2017 
> related to logic programming, program synthesis, and unification that you 
> might be interested in. You can find a list of talks and links to the 
> livestreams at con.racket-lang.org.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] [ANN] Porting PAIP's Prolog interpreter from Common Lisp to Racket, 1st version

[Matthias Felleisen]

> On Oct 13, 2017, at 3:01 PM, Luis Marcelo Rosso  wrote:
> 
> Hi all,
> 
> I am porting the Prolog interpreter shown in Peter Norvig's classic text on 
> AI, "Paradigms of Artificial Intelligence Programming: Case Studies in Common 
> Lisp 1st Edition", 
> https://www.amazon.com/Paradigms-Artificial-Intelligence-Programming-Studies/dp/1558601910/,
>  also known as PAIP, in its chapter 11, "Logic Programming".
> 
> I have just ended its first version, corresponding to section 11.2, and 
> shared:
> the code at https://github.com/promesante/paip-racket/
> the experience in 
> https://promesante.github.io/2017/10/12/porting_paips_prolog_interpreter_from_common_lisp_to_racket/
> 
> Enhancement suggestions more than welcome.



Thanks for sharing. 

Implementing a Prolog (in Scheme 84) was also my first adventure into the world 
of 
parentheses. The year was 1984 and it was a ton of fun. Someone scanned it in 
eventually (because I lost all my sources when I moved here from Rice): 

 https://www2.ccs.neu.edu/racket/pubs/#tr182-f

If you take a look, it is _not_ an interpreter but a compiler from Prolog to 
(). 
Dorai S.’s Racklog implementation of Prolog is an extension of this work. 

;; - - - 

Having said that, you wrote that you wanted to explore Racket because it is a
a “language hothouse” (a slogan we used for a while). Your interpreter-based 
Prolog implementation is not what we meant with that. You could indeed
implement this interpreter in any old language in a straightforward manner. What
we do mean is the macro-based approach, which allows a short-and-sweet 
transpiler 
from here to there (for some value of here and there). 

Keep pushing — Matthias



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket gui iconize behaviour

[Matthias Felleisen]

> On Oct 14, 2017, at 6:55 AM, Ran Mackeson  wrote:
> 
> Htdp and Racket have given me much enjoyment. I have just started to play 
> with racket gui. My Racket version is 6.10.1 and on both Linux Mint 17 and 
> Ubuntu 16.04 the behaviour of  'iconize' puzzles me:
> 
> #lang racket/gui
> 
> (define frame
>   (new frame%
>[label "Example"]
>[width 400]
>[height 300]))
> 
> (send frame show #t)
> 
> Now (send frame iconize #t) minimises the frame, but following it with (send 
> frame iconize #f) does not restore it.



I tried this after copying-and-pasting your code into the Defs area of drracket 
and running it: 

> Welcome to DrRacket, version 6.10.1.2--2017-10-09(-/f) [3m].
> Language: racket/gui, with debugging.
> > (send frame iconize #t)
> > (send frame iconize #f)

and I got the exact right behavior on a Mac OS X [very recent version] and not 
quite git head for DrRacket. 


Could you please share 

 — your platform 
 — your drracket version 

You may also just file a bug report via drracket. It gathers this information 
automatically. 


Thanks. 


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: code reflection

['John Clements' via Racket Users]

Lovely! I was thinking along these lines, but you hit it out of the park. 
Sounds like you must be avoiding some really important task!

John

> On Oct 14, 2017, at 11:31, Ryan Culpepper  wrote:
> 
> On 10/14/2017 05:01 AM, George Neuner wrote:
>> On 10/14/2017 3:00 AM, Jack Firth wrote:
>>> 
>>>So is there a way ... from normal code ... to get at the locals of
>>>functions higher in the call chain?  Or at least the immediate
>>>caller?
>>>Some reflective capability that I haven't yet discovered?
>>> 
>>> 
>>> I'm not sure if there's a way to do that, but I'm wondering if what you 
>>> want to do can be achieved more simply with plain functions and a very 
>>> small macro wrapper. In particular, I suspect putting too much logic in the 
>>> macro is what led you to eval which is the root of all evil. From what I 
>>> can tell there shouldn't be any need at all for eval or any sort of dynamic 
>>> runtime compilation to do things like what you're describing. Could you 
>>> give a few more details about your use case? Ideally with some example code 
>>> illustrating the problem?
>> Basically, this is a sort of Unix at-like function for flexible scheduling.  
>> It takes an expression containing dates, times, certain keywords and 
>> arbitrary numeric expressions, and it produces seconds since the epoch.  
>> Code is attached - hope it survives posting to the list.  It should be 
>> runnable as is.
>> What led me to eval originally was wanting to reference arbitrary 
>> functions/variables from the runtime environment.  I'd like to be able to say
>> things like:
>>(let [(y 42)] (schedule (at now + y mins) ...))
>> and similar involving top-level defined functions [which already works with 
>> eval].
>> I know that eval is not needed if I generate inline code rather than having 
>> the macro invoke a normal function.  But that is complicated by having to 
>> deal with free form expressions: they can have internal references between 
>> things which are not necessarily adjacent.  It is doable, but at some 
>> expense and not very cleanly.
>> I started out going the "compile" route - just generating inline code.  But 
>> as more functionality was added, that became unwieldy. So I switched to a 
>> runtime function. Right now the assoc list code is overly complex [so please 
>> ignore it] - it is there as a debugging tool until I get everything working 
>> exactly right.
> 
> Your example above shows that you want the `at` macro to accept a mixture of 
> Racket expressions and syntax that you interpret. If you want to accept 
> Racket expressions, you must leave them as syntax objects. Once you flatten 
> them with `syntax->datum`, there is *no way* to *correctly* recover their 
> meaning.
> 
> Here's my attempt to adapt the HtDP design recipe to a scaled-down version of 
> this problem.
> 
> First, let's think about the syntax (grammar) that `at` should accept. Let's 
> call it a Time. What are some reasonable Times?
> 
>  now
>  now + 30 ;; means 30 seconds
>  today
>  tomorrow + 20 mins
>  now + x mins + (/ ms 1000) secs
>  "2017-10-14 1:17:25" + 30 mins
> 
> But there are also some terms that are nonsense as Times:
> 
>  12
>  today + tomorrow
>  now mins
> 
> Let's say (as a place to start) that a Time consists of an absolute reference 
> point (like now or today) and some number of offsets. Here's a grammar:
> 
>  ;; Time = TimeBase {+ TimeExt}*
>  ;; TimeBase = now | today | String[Date]
>  ;; TimeExt = Expr[Real] MaybeUnit
>  ;; MaybeUnit =  | secs | mins
> 
> Let's call the *meaning* of a Time a TimeVal, and let's represent it as a 
> real number of seconds, using the same epoch as (current-seconds).
> 
>  ;; A TimeVal is a real number of seconds
>  ;; using the same epoch as (current-seconds)
> 
> The meaning of TimeBase is also a TimeVal. The meanings of TimeExt and 
> MaybeUnit are both Real (they are duration and durations scales; they have no 
> epoch).
> 
> Now to translate that plan to Racket.
> 
> First, turn keywords like `now` into "illegal use" macro definitions:
> 
>  (begin-for-syntax
>(define (at-keyword stx)
>  (raise-syntax-error #f "illegal use of `at` keyword" stx)))
>  (define-syntax now at-keyword)
>  (define-syntax today at-keyword)
>  (define-syntax secs at-keyword)
>  (define-syntax mins at-keyword)
> 
> Then define syntax classes for the nonterminals in the grammar. I'll also 
> define an `expr` attribute to compute the meaning of each term. For example, 
> the syntax class for TimeBase is
> 
>  (begin-for-syntax
>(define-syntax-class TimeBase
>  #:attributes (expr) ;; expression of TimeVal
>  #:literals (now today)
>  (pattern now
>   #:with expr #'(current-seconds))
>  (pattern today
>   #:with expr #'(today-fun))
>  (pattern s:str
>   #:with expr #'(parse-date-string s
> 
> To avoid complicating the syntax class and also to avoid making the expansion 
> bigger than 

Re: [racket-users] Intro and projects inquiry

[Jack Firth]

>
> > Racket doesn't play well with existing code bases (except C things) 
> > and so my hypothesis is simply that to gain adoption of Racket, you 
> > need to solve problems that aren't in the "production path." Good 
> > thing there are *lots* of those! All those Python scripts you have? 
> > All of those Perl scripts that no one understands anymore? Those are, 
> > in my opinion, the way in. 
>
> Funny story: That's how I cam back to Racket/Scheme. Several years ago I 
> worked on a web application written in Common Lisp. I needed some 
> "electronic duct tape" work done. I didn't use Common Lisp because of 
> its slow startup time and I was unhappy with shell scripts either. 
> Therefore I remembered that there was PLT Scheme/Racket around with 
> "batteries included". So nowadays lot of these tasks are now done using 
> Racket. 
>

There are some really neat packages that help make writing these sorts of 
scripts in Racket
easier. The Rash  language is designed 
with a line-based syntax and pipelining features similar
to traditional shell scripting languages, but because it's a Racket lang 
you can import Racket
libraries for use in your script and you can extract parts of your shell 
script into regular Racket
modules as the script grows in complexity.

There's also the Scripty  language, 
which does something a bit weird: it lets you write what
packages a script depends on inside the script itself, and when the script 
is run it will automatically
check to see if they're installed and prompt the script user to install 
them if they're not. This lets
you use whatever packages you like in your Racket scripts without burdening 
your coworkers with
the task of making sure those packages are installed and up to date before 
trying to run the script.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: code reflection

[Ryan Culpepper]

On 10/14/2017 05:01 AM, George Neuner wrote:


On 10/14/2017 3:00 AM, Jack Firth wrote:


So is there a way ... from normal code ... to get at the locals of
functions higher in the call chain?  Or at least the immediate
caller?
Some reflective capability that I haven't yet discovered?


I'm not sure if there's a way to do that, but I'm wondering if what 
you want to do can be achieved more simply with plain functions and a 
very small macro wrapper. In particular, I suspect putting too much 
logic in the macro is what led you to eval which is the root of all 
evil. From what I can tell there shouldn't be any need at all for eval 
or any sort of dynamic runtime compilation to do things like what 
you're describing. Could you give a few more details about your use 
case? Ideally with some example code illustrating the problem?


Basically, this is a sort of Unix at-like function for flexible 
scheduling.  It takes an expression containing dates, times, certain 
keywords and arbitrary numeric expressions, and it produces seconds 
since the epoch.  Code is attached - hope it survives posting to the 
list.  It should be runnable as is.


What led me to eval originally was wanting to reference arbitrary 
functions/variables from the runtime environment.  I'd like to be able 
to say

things like:

    (let [(y 42)] (schedule (at now + y mins) ...))

and similar involving top-level defined functions [which already works 
with eval].


I know that eval is not needed if I generate inline code rather than 
having the macro invoke a normal function.  But that is complicated by 
having to deal with free form expressions: they can have internal 
references between things which are not necessarily adjacent.  It is 
doable, but at some expense and not very cleanly.


I started out going the "compile" route - just generating inline code.  
But as more functionality was added, that became unwieldy. So I switched 
to a runtime function. Right now the assoc list code is overly complex 
[so please ignore it] - it is there as a debugging tool until I get 
everything working exactly right.


Your example above shows that you want the `at` macro to accept a 
mixture of Racket expressions and syntax that you interpret. If you want 
to accept Racket expressions, you must leave them as syntax objects. 
Once you flatten them with `syntax->datum`, there is *no way* to 
*correctly* recover their meaning.


Here's my attempt to adapt the HtDP design recipe to a scaled-down 
version of this problem.


First, let's think about the syntax (grammar) that `at` should accept. 
Let's call it a Time. What are some reasonable Times?


  now
  now + 30 ;; means 30 seconds
  today
  tomorrow + 20 mins
  now + x mins + (/ ms 1000) secs
  "2017-10-14 1:17:25" + 30 mins

But there are also some terms that are nonsense as Times:

  12
  today + tomorrow
  now mins

Let's say (as a place to start) that a Time consists of an absolute 
reference point (like now or today) and some number of offsets. Here's a 
grammar:


  ;; Time = TimeBase {+ TimeExt}*
  ;; TimeBase = now | today | String[Date]
  ;; TimeExt = Expr[Real] MaybeUnit
  ;; MaybeUnit =  | secs | mins

Let's call the *meaning* of a Time a TimeVal, and let's represent it as 
a real number of seconds, using the same epoch as (current-seconds).


  ;; A TimeVal is a real number of seconds
  ;; using the same epoch as (current-seconds)

The meaning of TimeBase is also a TimeVal. The meanings of TimeExt and 
MaybeUnit are both Real (they are duration and durations scales; they 
have no epoch).


Now to translate that plan to Racket.

First, turn keywords like `now` into "illegal use" macro definitions:

  (begin-for-syntax
(define (at-keyword stx)
  (raise-syntax-error #f "illegal use of `at` keyword" stx)))
  (define-syntax now at-keyword)
  (define-syntax today at-keyword)
  (define-syntax secs at-keyword)
  (define-syntax mins at-keyword)

Then define syntax classes for the nonterminals in the grammar. I'll 
also define an `expr` attribute to compute the meaning of each term. For 
example, the syntax class for TimeBase is


  (begin-for-syntax
(define-syntax-class TimeBase
  #:attributes (expr) ;; expression of TimeVal
  #:literals (now today)
  (pattern now
   #:with expr #'(current-seconds))
  (pattern today
   #:with expr #'(today-fun))
  (pattern s:str
   #:with expr #'(parse-date-string s

To avoid complicating the syntax class and also to avoid making the 
expansion bigger than necessary, factor run-time behavior out into 
helper functions, like `today-fun`:


  ;; today-fun : -> TimeVal
  (define (today-fun)
(define today (current-date))
(find-seconds 0 0 0 (date-day today) (date-month today) (date-year 
today)))


Here's the syntax class for TimeExt. It uses `expr/c` to make sure the 
given Racket expression actually produces a number.


  (begin-for-syntax

[racket-users] Racket gui iconize behaviour

[Ran Mackeson]

Htdp and Racket have given me much enjoyment. I have just started to play 
with racket gui. My Racket version is 6.10.1 and on both Linux Mint 17 and 
Ubuntu 16.04 the behaviour of  'iconize' puzzles me:

#lang racket/gui

(define frame
  (new frame%
   [label "Example"]
   [width 400]
   [height 300]))

(send frame show #t)

Now (send frame iconize #t) minimises the frame, but following it with 
(send frame iconize #f) does not restore it.

 I am very much a Racket newcomer so it is probable that I am being a bit 
stupid ...  Am I mistaken in expecting the frame to be restored?


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Daniel Brunner]

Am 13.10.2017 um 00:20 schrieb Andrew Gwozdziewycz:
> Racket doesn't play well with existing code bases (except C things)
> and so my hypothesis is simply that to gain adoption of Racket, you
> need to solve problems that aren't in the "production path." Good
> thing there are *lots* of those! All those Python scripts you have?
> All of those Perl scripts that no one understands anymore? Those are,
> in my opinion, the way in.

Funny story: That's how I cam back to Racket/Scheme. Several years ago I
worked on a web application written in Common Lisp. I needed some
"electronic duct tape" work done. I didn't use Common Lisp because of
its slow startup time and I was unhappy with shell scripts either.
Therefore I remembered that there was PLT Scheme/Racket around with
"batteries included". So nowadays lot of these tasks are now done using
Racket.

Daniel


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: code reflection

[George Neuner]

On 10/14/2017 3:00 AM, Jack Firth wrote:


So is there a way ... from normal code ... to get at the locals of
functions higher in the call chain?  Or at least the immediate
caller?
Some reflective capability that I haven't yet discovered?


I'm not sure if there's a way to do that, but I'm wondering if what 
you want to do can be achieved more simply with plain functions and a 
very small macro wrapper. In particular, I suspect putting too much 
logic in the macro is what led you to eval which is the root of all 
evil. From what I can tell there shouldn't be any need at all for eval 
or any sort of dynamic runtime compilation to do things like what 
you're describing. Could you give a few more details about your use 
case? Ideally with some example code illustrating the problem?


Basically, this is a sort of Unix at-like function for flexible 
scheduling.  It takes an expression containing dates, times, certain 
keywords and arbitrary numeric expressions, and it produces seconds 
since the epoch.  Code is attached - hope it survives posting to the 
list.  It should be runnable as is.


What led me to eval originally was wanting to reference arbitrary 
functions/variables from the runtime environment.  I'd like to be able 
to say

things like:

   (let [(y 42)] (schedule (at now + y mins) ...))

and similar involving top-level defined functions [which already works 
with eval].


I know that eval is not needed if I generate inline code rather than 
having the macro invoke a normal function.  But that is complicated by 
having to deal with free form expressions: they can have internal 
references between things which are not necessarily adjacent.  It is 
doable, but at some expense and not very cleanly.


I started out going the "compile" route - just generating inline code.  
But as more functionality was added, that became unwieldy. So I switched 
to a runtime function. Right now the assoc list code is overly complex 
[so please ignore it] - it is there as a debugging tool until I get 
everything working exactly right.


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.
For more options, visit https://groups.google.com/d/optout.
#lang racket/base

(require
  (for-syntax racket/base
  racket/format
  racket/pretty
  )

  racket/base
  racket/match
  racket/list
  racket/format
  racket/dict
  racket/date
  racket/port
  )


(provide
 at
 at-time
 month/year
 )


;%%%
#|

allows free form date/time descriptions in
the style of the Unix "at" command. converts
the description into seconds since the Unix
epoch: 1970-01-01 at 00:00hrs.

the resulting seconds value may be converted
into a usable date structure, or passed to
an alarm event for scheduling.

freestanding + operators will be ignored.
for signed values use [+-]?[:digits:]+.

key words:
  "now" = current date/time
  "today"  - at 00hrs
  "tomorrow"   - at 00hrs
  "this-month" - at 00hrs on the 1st
  "next-month" - at 00hrs on the 1st

dates must be entered in -mm-dd format.

times are 24hr format: hours and minutes
are required - seconds are optional.  a
separate AM/PM qualifier can be used to adjust
ambiguous times.

anything not a date, time or keyword will be
evaluated as a racket expression. expressions
may reference variables or functions from the
surrounding code environment.

an expression may be followed immediately by
a unit multiplier.  units may be seconds,
minutes, hours, days, or weeks (or some of
the typical abbreviations for these units).

|#
;%%%


;==
;
;  macro interface - generates call to
;  parsing function at runtime
;
;==

(define-syntax (at stx)
  (let* [
 (input   (cdr (syntax->datum stx)))
 (input   (map ~a input))
 (fnspec  (list 'apply '+ (list* 'at-time input)))
]

(datum->syntax stx fnspec)
))


;%%%


;==
;
;  parse a time/date description
;
;==


(define (at-time #:namespace [ns (current-namespace)] . input)
  (let* [
 (now(current-seconds))
 (today  (current-date))
 (hour12 (* 12 60 60))
 (hour13 (* 13 60 60))
]

(let loop [
   (input  input)
   (output '())
  ]
  
  (match input
  
; done
([? empty?]
 (eprintf "=> ~s~n" (reverse output))
 (map cdr output)
 )


; current time
([list "now" _ ___ ]
 (loop (cdr input) (cons (cons 'now now) output)))


; date (at 00:00:00)
([list (pregexp px-date [list _ 

[racket-users] Re: code reflection

[Jack Firth]

>
> So is there a way ... from normal code ... to get at the locals of 
> functions higher in the call chain?  Or at least the immediate caller? 
> Some reflective capability that I haven't yet discovered? 
>

I'm not sure if there's a way to do that, but I'm wondering if what you 
want to do can be achieved more simply with plain functions and a very 
small macro wrapper. In particular, I suspect putting too much logic in the 
macro is what led you to eval which is the root of all evil. From what I 
can tell there shouldn't be any need at all for eval or any sort of dynamic 
runtime compilation to do things like what you're describing. Could you 
give a few more details about your use case? Ideally with some example code 
illustrating the problem?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] code reflection

[George Neuner]

Hi all,

This is a bit difficult to explain, so bear with me.

I have a very simple macro which generates a runtime call to a normal
function.  The macro is so the arguments can be [more or less] free
form expressions - the runtime function is because the computations
are not simple and some of them require current runtime information
like dates, times, etc.

I'd like to allow the [normal] function that processes the expressions
to reference variables and functions defined in the code surrounding
the macro invocation.  I can get at top-level defines using eval, but
thus far I can't figure out how to get at locals in a function that is
invoking the macro.

I know that I can do this if I go the "compile" route, generating code
to do the computations inline rather than punting to a runtime
function.  The issue I have with that is that some uses would end up
generating quite a bit of code, and a program that used the macro
extensively would swell accordingly.

So is there a way ... from normal code ... to get at the locals of
functions higher in the call chain?  Or at least the immediate caller?
Some reflective capability that I haven't yet discovered?

If not, I'll just go the "compile" route and live with it. 

Thanks,
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: [ANN] Porting PAIP's Prolog interpreter from Common Lisp to Racket, 1st version

[Jack Firth]

This is really cool, thanks for writing about it and sharing it! And thanks 
for showing me another book I ought to get around to reading.

There were some very interesting talks last weekend at RacketCon 2017 
related to logic programming, program synthesis, and unification that you 
might be interested in. You can find a list of talks and links to the 
livestreams at con.racket-lang.org.

-- 
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.
For more options, visit https://groups.google.com/d/optout.