[racket-users] Generics: delegate to a parent

[zeRusski]

Hi all.

I am trying to make good use of Generic Interfaces, but can't figure out if 
its at all possible to delegate calls up the struct inheritance chain. So, 
something like `call-next`, or even better maybe there's a way to do 
explicit dispatch? So something like having two structs:

(struct fish ())
(struct marlin (fancy))

Both implement the same generic interface. Far as I can tell dispatch will 
choose marlin's implementation on that kind of instance. Is there a way for 
me to delegate to fish's method from inside marlin's method with the same 
name? I can introduce a level of indirection and extract fish's 
implementation into a function that I could call from marlin's method but 
that feels wrong somehow. Am I asking too much from Racket generics?

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] Generics: delegate to a parent

[zeRusski]

>
> object system (which also cooperates with generics)


TBH I've been avoiding Racket object system since my needs are typically 
limited and don't call for full blown OOP. I only casually looked at what 
its capable of, I guess may need to revisit. I was rather hoping for 
something as simple as structs and generics a-la Emacs Lisp. Superficially 
Racket structs appear to be like those in Emacs Lisp and Clojure, but now 
that I'm using them more I'm starting to doubt that. They feel lower level 
(although quite rich) - the kind of cloth you use to build everything else. 
I feel like Racket could use a more nimble data type with identity than 
structs, yet not as ad-hoc as hash-tables. Well, nothing stops one from 
implementing that, I suppose.

-- 
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] Thread safe operations and shared memory

[zeRusski]

Racket documentation doesn't tell much on the subject. The only two things 
I've found are *box-cas! *and this passage from Evaluation Model that to me 
remains a bit cryptic.

Threads are created explicitly by functions such as thread 
> .
>  
> In terms of the evaluation model, each step in evaluation actually consists 
> of multiple concurrent expressions, up to one per thread, rather than a 
> single expression. The expressions all share the same objects and top-level 
> variables, so that they can communicate through shared state, and 
> sequential consistency is guaranteed (i.e., the result is consistent with 
> some global sequence imposed on all evaluation steps across threads). Most 
> evaluation steps involve a single step in a single expression, but certain 
> synchronization primitives require multiple threads to progress together in 
> one step.


Could someone illuminate how I should be thinking about mutation in 
presence of multiple green threads? E.g. mutate shared mutable hash-table, 
mutate mutable hash-table held in in a struct field? Basically, I'm trying 
to decide when to reach for mailboxes and other synchronization primitives. 
If I'm ok with "eventually" other threads will see that value, should I 
think hard about mutating things?

What's comparable to Clojure atoms? Would it be boxes + box-cas!?

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] Thread safe operations and shared memory

[zeRusski]

Thank you George for thorough explanation. 

(set!) of a box, an mcons, or a *struct field* is atomic WRT threads


So, the `foo-struct-set!` would be atomic, but (hash-set! 
(foo-struct-field-with-table foo) key value) would not (assuming a mutable 
hash-table value there), correct?

-- 
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] Does Racket have a sexp-syntax regular expressions?

[zeRusski]

I swear someone told me there was a Racket lib equivalent of Emacs Lisp rx 
or Shivers's trx regular expressions, yet I failed to find one. Any 
pointers?

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] Does Racket have a sexp-syntax regular expressions?

[zeRusski]

No wait. I meant SRE-like to match strings, not TRX to match trees. Messed up 
there, sorry

-- 
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] Does Racket have a sexp-syntax regular expressions?

[zeRusski]

That's it! Thank you Philip and Jay


On Wednesday, 27 March 2019 12:48:37 UTC, Philip McGrath wrote:
>
> You'll want to look at `parser-tools/lex-sre`: 
> https://docs.racket-lang.org/parser-tools/Lexers.html#(mod-path._parser-tools%2Flex-sre)
> -Philip
>
>
> On Wed, Mar 27, 2019 at 8:45 AM zeRusski  > wrote:
>
>> No wait. I meant SRE-like to match strings, not TRX to match trees. 
>> Messed up there, sorry
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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] Error location in test submodules

[zeRusski]

I am a big fan of having tests alongside code so (module+ test ...) is 
magic. The only annoyance I've been running into lately is error reporting. 
If I have many test chunks spread around my code and some code change 
throws an exception or a contract violation it is impossible to tell which 
test triggered it. The only thing in the context is (submod "file.rkt" 
test):1:1. On occasion you get the exact point the exception happened but 
again no context, so no way to figure which check specifically ran the 
buggy code. Normally I would go through a dance of bisecting to pinpoint 
the culprit, but now that I have many tests its become a major pain. Is 
there a better way?

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] Error location in test submodules

[zeRusski]

>
> > Are you using emacs racket-mode?
>
> I am, almost exclusively. Exception and check failure locations can be a 
> pain, but they work in general.
>
 
What Eric said :) But when in doubt I always compare behavior with DrRacket 
and raco, and racket-mode stands tall here and does at least what they do, 
so it isn't one to point fingers at.
 

> The third check is never invoked. While evaluating the argument, f throws 
> an exception and the REPL gives no useful context. I think you're asking 
> specifically about this case. If the error is in the code being tested and 
> not in the test itself, I'd want to know where the exception was raised.
>
> In Emacs, hitting C-u C-c C-c inside the test sub-module exposes the 
> context I'm looking for:
>
> ; ...
> 
> ; error: FAIL
> ; Context (errortrace):
> ;/tmp/somefile.rkt:2:15: (error (quote FAIL))
> ; ...
>


Eric, that's exactly what I'm asking about - perfect example - thank you. 
However that "context" you speak of isn't terribly helpful. It does indeed 
point where error occurs - ok'ish when its in the surrounding module you 
control, completely useless when its in some library or collection or 
kernel - but notice how it doesn't tell you which (check ...) triggered it, 
so if you have many of those, how in the world could you tell? That 
f-function that throws could be called by any number of other functions and 
code. See what I mean?

 

> If I'm generating tests with macros, getting the source locations right 
> can be a hassle. Sometimes, it's easier to just add with-check-info:
>

Oh wow, this is great. Wasn't aware of this nifty macro! I can see how I 
could wrap every rackunit check in something that effectively names it, so 
that you could see who triggered an error. Just like in your example. 
That's basically wrapping rackunit with your preferred interface - requires 
work, but would help. Your solution comes very close to what I want. I 
wonder why something like this isn't the default. Simply haven't the time 
to implement and provide it to public, or people don't usually feel the 
need for it? If the latter, then is my test-debug flow doesn't match what 
Racket expects me to do?

 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] Error location in test submodules

[zeRusski]

> #lang racket/base
> (define f (λ _ (error 'FAIL)))
> (module+ test
>   (require rackunit)
>   (define OK (string->unreadable-symbol "OK"))
>   (define-syntax-rule (check-OK-form expr)
> (let ([val expr])
>   (with-check-info (['input 'expr] ['expected OK] ['actual val])
> (check eq? val OK
>   (check-OK-form OK)
>   *(check-OK-form (values #f))*
>   (check-OK-form (f)))
>
> Even without a C-u prefix, the input can help locate the offending check:
>
> 
> ; FAILURE
> ; /tmp/somefile.rkt:9:8
> input:  (values #f)
> expected:   OK
> actual: #f
> name:   check
> location:   somefile.rkt:9:8
> 
> ; error: FAIL
> ; Context:
> ;  (submod "/tmp/somefile.rkt" test):1:1 [running body]
>

Argh, I was too hasty to declare the with-check-info the winner here. Note 
that you get this extra info when the check actually fails, in your example 
above the (values #f) case fails, note the next one that calls (f) that 
throws. In this latter case the stack is nowhere to be found and no extra 
check info is present, so you are essentially back to square one, sigh. Now 
this really bothers me cause all of my tests turn into a black box that I 
need to poke and prod whenever something breaks.

-- 
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] Error location in test submodules

[zeRusski]

> If you want your tests to catch exceptions you need to wrap them in 
> exception handlers, which you could write a macro to do for you; as Eric 
> noted though you need to be careful to preserve source locations.
>

This gave me an idea, so I've been reading *rackunit* docs finally. I'm 
about halfway through and I don't exactly understand the machinery yet but 
with your note above and what I've read so far the following code actually 
does what I want:

(module+ test
>   (require rackunit)
>   (define-check (my-check pred thunk)
> (with-handlers ((;; exn predicate
>  (λ (exn) (and (not (exn:test:check? exn))
>(exn:fail? exn)))
>  ;; exn handler
>  (λ (e) (with-check-info (('exn (make-check-info 
> 'error e)))
>   (fail-check)
>   (check-pred pred (thunk
>   ;; throws
>   (my-check identity (thunk (f)))
>   ;; fails
>   (check eq? 2 3)
>   ;; succeeds
>   (check eq? 3 3))


Here's the output that preserves location of the check that failed:


; FAILURE
; /Users/russki/Code/fcgi-rkt/play.rkt:24:2
name: my-check
location: play.rkt:24:2
params: '(# #)
exn:
#(struct:check-info error #(struct:exn:fail "f-failed" 
#))


; FAILURE
; /Users/russki/Code/fcgi-rkt/play.rkt:26:2
name: check
location: play.rkt:26:2
params: '(# 2 3)


This is a good start I think. To make it useful you'd want to capture the 
errortrace somehow, unpack and report it in the check-info. That is you 
report both the failed test location and the exception with its errortrace. 
I'm sure I'll soon find out how to do all that so that a) rackunit API is 
used and b) report follows Racket and rackunit style as much as possible. 
If you can help of top of your head, that'd be great. Also note the 
necessity of wrapping the test body in a thunk, which is annoying but 
understandable and the docs make a note as to why that is. We could fix 
that and other boilerplate with a macro. I'm just trying to think how I 
could minimize the damage to *rackunit* proper. Speaking of ...

It is tempting to build my own thing for testing but I'll resist it as best 
I can. I'd much rather just have a tiny macro that doesn't interfere with 
rackunit and doesn't impose my oft ill-advised and rash preconceptions. The 
more I read rackunit docs the more I'm convinced I wouldn't be able to 
improve on it without making a big mess. It is possible that I'm going to 
run into more annoying little gotchas that I'd want to fix, but I'm not 
there, yet. Please, don't let my current attitude stop you.

-- 
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] Pattern: reusing the same name in macro-generated definitions

[zeRusski]

While reading *rackunit* source I stumbled on a pattern that I can't figure 
out. Why the heck does it work? Condensed to its essence it amounts to 
introducing indirection with a macro-generated define:

#lang racket
> (require (for-syntax syntax/parse)
>  syntax/parse/define)

 


> (define-simple-macro (define-foo (name:id formal:id ...) body:expr ...)
>   (begin
> (define (foo-impl formal ...) body ...)
> (define-syntax (name stx)
>   (syntax-parse stx
> [(_ . args) #'(foo-impl . args)]
> [_:id #'(λ args (apply foo-impl args))]

 


> (define-foo (bar op a b) (op a b))
> (define-foo (baz op a b) (op a b))
> ;; Why am I not getting this error?
> ;; 
> ; module: identifier already defined
> ;   at: foo-impl



See that *foo-impl* there? The same name is being reused every time the 
*define-foo* macro is called. I would've expected Racket to shout at me 
that I'm attempting to redefine something, but it doesn't and magically it 
works. Why? Say, in Elisp or Clojure I would've gensymed that symbol. What 
am I missing? Does Racket perform some clever renaming to preserve hygiene 
or something? Could someone please help me reason through this.

Original source: 
https://github.com/racket/rackunit/blob/master/rackunit-lib/rackunit/private/check.rkt#L110

PS: also I left that second clause there just cause it just dawned on me 
how cool it is that we can use macros in identifier position :)

-- 
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] Pattern: reusing the same name in macro-generated definitions

[zeRusski]

I know in principle but on occasion I fail to understand the implications.  
Let me think aloud. I don't have to be perfectly accurate, maybe just about 
right. Hygiene here means that every symbol there e.g. arguments my macro 
receives carry their "environment" with them. There exists some oracle 
which can tell when two symbols refer to the same thing probably by 
checking environments somehow. Since I just typed that *foo-impl* there in 
the template it must be getting some fresh tag or "environment" attached to 
it to avoid capturing something with the same name defined at the macro 
call site, right? Ok. How the *define* before *foo-impl *is special then? 
We both know the "define" I mean. Or is the newly attached "environment" is 
in fact not empty and comes enriched with a bunch of Racket stuff? How do I 
reason when its safe to just type a name and when it isn't? In fact, here. 
I just defined a foo-impl outside. If I now remove the macro-defined 
foo-impl the code will still work correctly and grab the outer definition. 
So define *inside* a template refers to the usual define, but *foo-impl* 
doesn't? Why?

(define (foo-impl op a b) (op a b))

(define-simple-macro (define-foo (name:id formal:id ...) body:expr ...)
 ... same ...

(define-foo (bar op a b) (op a b))
(define-foo (baz op a b) (op a b))
(bar + 1 2)
;; => 3



On Thursday, 4 April 2019 21:02:58 UTC+1, Ben Greenman wrote:
>
> Racket's macros are hygienic. They'll gensym for you. 
>

-- 
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] Pattern: reusing the same name in macro-generated definitions

[zeRusski]

> If I understand correctly, the fourth paragraph here is relevant? 
>
>   
> https://docs.racket-lang.org/reference/syntax-model.html#%28part._transformer-model%29
>  
>
>
I dreaded someone pointing me there. I read it a year ago, took a lot of 
head scratching and careful reading before I convinced myself that I'd 
grokked it. Both the vocabulary used and apparently my understanding 
dissipated after a year. Had to read it again :)
 

> So, `foo-impl` is a binding introduced by the macro and gets that 
> macro invocation's fresh macro-introduction scope. 
>
> Whereas for example `name` is syntax coming from outside the macro, 
> and doing `(define-foo (blerg ___) ___)` twice would be an error due 
> to redefining `blerg`. 
>

Ok. Let's see if I can explain away all mysteries by carefully following 
the syntax and expansion model. Someone please read it through and poke 
holes. In the process, if I'm not mistaken, we are going to discover an 
error in the Scopes section of the docs.

Step aside everyone, I'm putting my Matthew hat on. Here goes nothing! 

We are trying to answer the following questions about this piece of code (I 
annotated some identifiers with indexes [in sq brackets]):

(define[1] (foo-impl[1] op a b) (op a b))

(define-simple-macro (define-foo (name:id formal:id ...) body:expr ...)
  (begin
(define[2] (foo-impl[2] formal ...) body ...)
(define-syntax (name stx)
 .
  (foo-impl[3] . args)
 .)))

(define-foo (bar op a b) (op a b))[4]
(define-foo (baz op a b) (op a b))[5]
(bar + 1 2)


Q1: My original question was why the two call sites [4] and [5] do not 
> complain about redefinition of /foo-impl/. After all every time the 
> transformer is invoked it generates a definition of the same identifier 
> /foo-impl/, which I can easily see in macro-expansion at the relevant call 
> site. However, if I were to type /foo-impl/ definitions by hand at 
> top-level or module level Racket would yell at me. Why the two cases look 
> about the same (i.e. end up producing visually the same code) but invoke 
> different reaction from the compiler?


Suppose the transformer at [4] did its job and we are now evaluating the 
code it produced, that is the binding [2] it introduced and that use of 
/foo-impl/ at [3]. Generated [2] will have at least two scopes: one from 
the macro definition site i.e. /define-foo/, the other is the fresh 
macro-introduction scope. When the reference to /foo-impl/ at [3] gets 
resolved we'll be looking for bindings of /foo-impl/ whose scope sets are 
subsets of the reference, that is of the identifier at [3]. In fact we find 
two such bindings: [1] and [2]. Which one do we choose? We choose the one 
whose scope set is the superset of any other binding we discovered. Here 
[2] has at least one extra scope (macro-intro scope) compared to [1], so we 
use [2].

Now, why is there are no ambiguity as to which /foo-impl/ to use when we 
expand and eval [5]? Well, we'll go through the same motions, but there 
will be one extra /foo-impl/ binding generated at [4], so we'll have to 
choose from the total of 3 bindings when resolving any /foo-impl/ ref at 
[5]. And again we choose the [2] that is the result of expansion of [5].  
Why? Well, it'll have that fresh macro intro scope passed to the 
transformer from [5] and it differs from the macro intro scope at [4], so 
there is no ambiguity between the two generated bindings at [4] and [5]. 
For any ref to /foo-impl/ generated by [5] we reject the /foo-impl/ binding 
generated at [4] because its scope set isn't a subset of any ref at [5]. To 
choose between [1] and generated [2] we use the same logic as in the 
previous paragraph: [2] wins cause its scope set is bigger.

So, the three bindings  of identifier /foo-impl/ that the code above 
introduces at [1], [4] and [5] (latter two generated from the template at 
[2]) are not at all the same, at least not in the syntax model of Racket. 
Identifiers aren't merely compared by name, their scope sets have the final 
say in how identifiers are resolved.

Q2: My macro introduces a new binding for /foo-impl/ at [2]. How is that 
> identifier different from the /define/ identifier at [2]? That is to ask 
> why the /define/ at [2] is bound as we expect to the /define/ in Racket, 
> while any reference to /foo-impl/ in the subsequent template code refers to 
> the binding at [2].


The part about any /foo-impl/ ref in the template to the binding at [2] we 
already answered in Q1. Other bindings e.g. /define/ at [2] are again 
resolved as we discussed in Q1. This particular /define/ would resolve 
using the macro definition site, one of /define-foo/.

Q3: If we were to remove /foo-impl/ binding at [2] any template code would 
> happily refer to /foo-impl/ binding at [1]. How so?


Again Q1 kinda answers that. Put simply there are fewer /foo-impl/ bindings 
to choose from, and the one at [1] happens to have the scope set that is a 
subset of any use in the temp

Re: [racket-users] Pattern: reusing the same name in macro-generated definitions

[zeRusski]

A simple model to keep in your head: 
>   Each macro keeps a count, i,  of how many times it has been applied.
>   Each time a the output of a macro contains a definition of name not 
> present in the input it appends _i to the name.
>

Ha, I get it. That's a good little heuristic. I'm keeping it. Thanks. That 
index is a simplified model of that whole "fresh macro-introduction scope" 
business. I like it.

-- 
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] How to install local dir package replacing pre-installed one

[zeRusski]

I thought about hacking on /rackunit/ a bit and if it pans out maybe send 
my changes upstream. Typically I would clone a repo and then do raco pkg 
install in its folder so that I have it linked and code that may require it 
picks up latest changes. Very convenient workflow. Except /rackunit/ is 
special (no surprise there) it comes pre-installed and in the installation 
scope and basically other things depend on it, so don't touch it says 
/raco/. Here's what I tried next:

cd to rackunit parent dir and

raco pkg update -i --force --type dir ./rackunit/


but I don't see the "Linking directory ..." message there. Is it copying 
stuff? See, not only do I want my changes picked up automatically by other 
code, I also want to be able to jump to definition and arrive at that local 
repo. And its a good litmus test for whether I'm actually linking or moving 
stuff to collects somewhere.

Trying nuclear (but, really, I have no clue what I'm doing here):

~/Code/rackunit $ raco pkg remove --force rackunit
> ~/Code/rackunit $ raco pkg install --force
> Linking current directory as a package
> raco setup: version: 7.2.0.12


Looks good. Also I think I installed it as in -user scope. Except, nope. 
Jump to definition still takes me to some share 
racket-7.2.0.12/share/pkgs/rackunit-lib/rackunit/private.

Same goes for changing code in locally cloned repo. Changes aren't picked 
up. Is /rackunit/ special somehow? Or is there some weird PATH that's 
shadowing linked /rackunit/? Should I nuke dirs that mention /rackunit/ 
inside racket-7.2.0.12/share/

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.

[racket-users] Re: How to install local dir package replacing pre-installed one

[zeRusski]

If I'm reading docs right, then it should've worked, hm:

Conflict checking disallows installation of the same or conflicting package 
> in different scopes, but if such a configuration is forced, collections are 
> found first in packages with user package scope 
> . Search 
> then proceeds in a configured order, where installationpackage scope 
>  typically 
> precedes other directory package scopes 
> .


Source: 
https://docs.racket-lang.org/pkg/Package_Concepts.html#%28part._concept~3ascope%29


Also I'm seeing this:

~/Code/rackunit $ raco link -l

 


> User-specific, version-specific links:
>  collection: "rackunit"  path: "/Users/russki/Code/rackunit"
>
 

Installation links:
>
 collection: "typed"  path: 
> "/Users/russki/Code/racket-7.2.0.12/share/pkgs/rackunit-typed" 

 root  path: "/Users/russki/Code/racket-7.2.0.12/share/pkgs/rackunit-lib"
>  root  path: "/Users/russki/Code/racket-7.2.0.12/share/pkgs/rackunit-doc"
>  root  path: "/Users/russki/Code/racket-7.2.0.12/share/pkgs/rackunit-gui"
>  root  path: 
> "/Users/russki/Code/racket-7.2.0.12/share/pkgs/rackunit-plugin-lib"
>  root  path: "/Users/russki/Code/racket-7.2.0.12/share/pkgs/redex-pict-lib"


Also raco pkg show does show rackunit linked.

-- 
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: How to install local dir package replacing pre-installed one

[zeRusski]

Alright, I managed to install from local clone. Thank you Philip!

Some observations here. You were right, I should've cloned from my fork. 
Else `raco pkg update` keeps pulling from the original (Racket central) 
URL. Docs tell us we can supply alternative URL, and it works but sadly not 
for multi packages that share the same clone or repo. Yeah, raco docs tell 
us this too, so no 
complaints 
https://docs.racket-lang.org/pkg/git-workflow.html#%28part._clone-link%29

Either way, when raco pkg update pulls updates to the clone, it will still 
> pull them from the repository corresponding to ‹pkg-name›’s old source, and 
> not from the git remote ‹url›. Usually, that’s what package developers 
> want; when they’re not actively modifying a package, other developers’ 
> updates should be pulled from the package’s main repository. In case where 
> ‹url› is the preferred source of updates for raco pkg update, use ‹url› in


And indeed I confirmed that by running:

raco pkg update -j 8 --clone . 
> https://github.com/vkz/rackunit.git?path=rackunit


Which pulls from that fork but only rackunit and not its dependencies that 
in fact reside in the same repo, for those it keeps going to Racket 
central. Solution would be to use correct fork for the original clone, but 
I can't be bothered to go through that again. But IIUC I may as well just 
stick with git flow for managing my repo, where I control my remotes. 
Right? raco update doesn't really perform any magic beyond what I'd get by 
simply git pulling into a linked clone? 

Thank you for your help Philip and Alex. I have unmitigated fear of package 
managers. raco has been mostly good to me so far, but omg it is rich )))

-- 
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: How to install local dir package replacing pre-installed one

[zeRusski]

My celebration was a bit premature. Strangely jumping to definition now 
worked and sent me to the right location but no code changes were picked 
up. I read the docs some more and noticed that raco pgk show  showed actual 
checksum for /rackunit/ packages instead of #f and the source said /clone/ 
not /link/. After that I did a number of stupid things and managed to botch 
my packages so completely that even raco gave up and wouldn't stop 
demanding some missing rackunit files in some internal collects/ dir.

I gave up and did a clean Racket reinstall from source. Took a while. I 
imagine there must be a way to bootstrap packages without complete 
reinstall, but I don't know how.

I did manage to get what I want. Here:

git clone https://github.com/racket/rackunit.git
> cd rackunit

 


> # just install every subdirectory
> ~/Code/rackunit $ raco pkg install -j 8 --force -u --type dir rackunit*

 


> # verify
> ~/Code/rackunit $ raco pkg show --all --long --rx "rackunit*"

 


> Installation-wide:
>
 

  ... omitted but rackunit pkgs are still there ...

 

User-specific for installation "development":
>  PackageChecksumSource
>  rackunit   #f  (link 
> "/Users/russki/Code/rackunit/rackunit")
>  rackunit-doc   #f  (link 
> "/Users/russki/Code/rackunit/rackunit-doc")
>  rackunit-gui   #f  (link 
> "/Users/russki/Code/rackunit/rackunit-gui")
>  rackunit-lib   #f  (link 
> "/Users/russki/Code/rackunit/rackunit-lib")
>  rackunit-plugin-lib#f  (link 
> "/Users/russki/Code/rackunit/rackunit-plugin-lib")
>  rackunit-test  #f  (link 
> "/Users/russki/Code/rackunit/rackunit-test")
>  rackunit-typed #f  (link 
> "/Users/russki/Code/rackunit/rackunit-typed")


And yep, jump to definition works and changes are picked up.

In conclusion. I'm not really sure. I definitely went through a phase of 
cargo culting here, copying incantations I don't quite understand. Has the 
wider Racket community been bitten by that particular bug, yet? raco packs 
a lot of punch and plenty of docs to back that up, but it isn't always easy 
to figure it all out. I still don't understand this "multiple packages in 
the same repo" arrangement. For instance, raco merilly allowed me to 
install and link the root dir of rackunit. Turns out that does not include 
those subpackages. However if you do the --clone . trick that Philip 
suggested then it resolves deps and offers to install subdirs. But then 
/clone/ vs /link/ source are confusing, where the clone one isn't really 
linked, so code changes are ignored. Anyway, I guess I'm learning things 
here.

Thank you for your patience

-- 
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: Error location in test submodules

[zeRusski]

Alright, tried to fix it as I see fit. Naturally, my understanding of 
rackunit source doesn't go far, but here's the 
PR: https://github.com/racket/rackunit/pull/107

Just keeping it real with Racket, I guess.

-- 
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] Is there a way to find where some feature is implemented in racket?

[zeRusski]

I suspect I'm not the first to ask, but my search-fu has failed me here. 
Apologies if the question has already been answered on that list.

When I read Racket docs I sometimes wonder how a particular feature is 
implemented. Looking at the source sometimes shed light or simply teaches 
you things. However I find myself grepping Racket source and very often 
failing. Is there a better way? Latest such encounter was s-exp meta 
language. I assume its implemented somewhere, but grep mostly just shows 
scribblings or its use sites. What "algo" should I employ to find relevant 
source of a thing? Would be grand to have links from docs,  but its 
probably quite involved.

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] Is there a way to find where some feature is implemented in racket?

[zeRusski]

>
> Open DrRacket. 
> Use the feature in a syntactically correct way. 
> Click (depending on your OS) on the identifier to open defining file. 
>

ah, that works great least for identifiers in module body, thank you for 
showing this to me. I sometimes forget drracket packs some neat stuff. This 
doesn't work for say identifiers used as module meta-language like s-exp. 
But seems like Greg's suggestion to Open require path locates the lib in 
collections which is great! Along with visit definition this should cover 
most cases I hope.

Also, wait, all it took to define s-exp meta language ... was one line?! 
You racketeers need to get serious here, no wonder you can't find jobs. If 
you don't create work for yourself noone would. Go build 80% frameworks or 
smth

Thank you Matthias and Greg

-- 
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] Inline tests for library and corresponding lang result in a loading cycle

[zeRusski]

I wrote a library foo/bar.rkt and I also allow to use it as a #lang. 
Roughly the
structure is like this:

foo
├── bar
│   ├── lang
│   │   └── reader.rkt
│   └── main.rkt
├── bar.rkt

Most of the work happens in the library foo/bar.rkt, so naturally all of 
the tests
reside there. I'd like to be able to test library proper, but also use the 
syntax
of the language that I defined for it, so I try something like this and get 
a ...
cycle? Sadly, I can't figure out why. Could you please help me reason 
through
this.

  ;; foo/bar.rkt
  ;; ---
  (module+ test

(module lang-test foo/bar
  (provide run-language-tests)
  (define (run-language-tests) 42))

(define run (dynamic-require 'lang-test 'run-language-tests))
(run))

  ;; => error
  ;
  ; standard-module-name-resolver: cycle in loading
  ;   at path: /Users/russki/Code/foo/bar.rkt
  ;   paths:
  ;/Users/russki/Code/foo/bar.rkt

Far as I can tell cycle isn't due to dynamic-require there, but due to that
submodule declaration. This puzzles me, since the submod is declared with 
module,
not module+ or module*.

Other modules look as you'd probably expect:

  ;; foo/bar/lang/reader.rkt
  ;; ---
  #lang s-exp syntax/module-reader
  foo/bar/main

  ;; foo/bar/main.rkt
  ;; 
  #lang racket
  (require foo
   "../bar.rkt")

  (provide (except-out (all-from-out foo) #%app #%top)
   (rename-out [app #%app]
   [top #%top])
   (except-out (all-from-out "../bar.rkt") app top))

Now, if we move the lang tests into a separate file, the dynamic-require 
above
works out and no cycles are reported:

;; foo/lang-test.rkt
;; -
#lang foo/bar
(provide run-language-tests)
(define (run-language-tests) 42)

One hypothesis I have is that the (module lang-test foo/bar ...) doesn't 
resolve
to the language but rather to the foo/bar.rkt. There must be a way to 
reflect how
resolver works, but the closest I found was this:

(require syntax/modresolve)
(resolve-module-path 'foo/bar)

And indeed it resolves to foo/bar.rkt, but then I don't know if I'm even 
using it
correctly.

I may actually be doing something stupid here e.g. introducing ambiguity as 
to how
foo/bar is resolved (lang or lib) but this silliness brings about some 
things I'd
like to clarify and learn:

1. How would you write your tests in the situation like this when most of 
the work
   happens in the library but you also allow using it as #lang? I'd like to 
keep
   both kinds of tests local to the library, so I can run them as I code. 
Or at
   least be able to run tests that only test the lib and corresponding 
language.

2. Why does the above report a cycle? How do I reason about it, better 
still how
   do I query the resolver, reflect and debug?

Have I missed some important part in the docs about this?

I wonder if the following convo is related and basically tells me I can'd 
test a language like this cause I'd need a submod trick or something:
https://groups.google.com/forum/#!searchin/racket-users/cycle$20in$20loading%7Csort:date/racket-users/TXt6UtTBGBU/jVW8d94DBwAJ

-- 
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] catch and bind an unbound id in a macro

[zeRusski]

Here's what I've been trying and failing to do in Racket. The smallest 
example I
could think of is a macro that sets a key in a hash-table, so basically this
transformation:

  (set/define ht 'key 42)
  ;; =>
  (hash-set! ht 'key 42)


but if ht there is an unbound identifier it must bind it to a fresh hash 
table. So
basically introduce a (define ht (make-hash)) before setting the key. 
Assume we
run in a context where define is allowed.

Please, don't ask why I want something like this, I just do. So far tricks 
I could
use in other lisps failed in Racket. Here's one silly idea: catch unbound
identifier exn. You can do it as per below or in the handler itself but it 
doesn't
matter cause that define is local (I think) and doesn't happen in the macro 
use
context.

  (require (only-in syntax/macro-testing convert-compile-time-error))

  (define (unbound-id-error? err)
(and (exn:fail:syntax? err)
 (regexp-match #rx"unbound identifier" (exn-message err

  (define-syntax-rule (set/define id key val)
(unless (let/ec k
  (with-handlers ((unbound-id-error? (λ (_) (k #f
(convert-compile-time-error
 (hash-set! id key val
  (displayln "escaped")
  (define id (make-hash))
  (hash-set! id key val)))

  (set/define ht 'key 42)
  ;; =>
  ;; runs but appears that the (define ht ..) doesn't happen at top-level

This is already all sorts of ugly and it doesn't even work.

Another idea is to replace #%top for the extent of that transformer, perform
local-expand (or some equivalent) so that #%top expansion does the job. 
I've no
idea how to do that, but I'm sure Racket could be persuaded. Incidentally, 
I'm
curious how to create such local transformers e.g. something like 
(let-transformer((#%top ...)) body).

Even if I knew how to do the above (local-expand #'(set/define ht 'key 42) 
'())
run at compile time doesn't seem to wrap unbound ht in #%top. I thought it 
should?

So then, two questions:

1. What's the Racket way of getting what I want?

2. Is there a way to torture the above code into submission? Put 
differently is
   there a way to ensure (define id (make-hash)) runs in appropriate 
context? 

-- 
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] Inline tests for library and corresponding lang result in a loading cycle

[zeRusski]

>
> PS the `lang/reader.rkt` fandango is no longer necessary in modern Racket; 
> if you like, you can use a `reader` submodule in your primary language file.
>

Made me curious. Maybe I'm dense, but do you suggest that I delete 
foo/bar/lang and add this to foo/bar/main.rkt

(module reader syntax/module-reader
  foo/bar/main)

If I do that though #lang foo/bar no longer works, compiler keeps looking 
for lang/reader.rkt there, but #lang foo/bar/main does work. In that 
scenario how do I get my preferred foo/bar language back?

-- 
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] catch and bind an unbound id in a macro

[zeRusski]

Not quite what I had in mind. The following examples must all work without 
errors:

#lang racket

;; set/define defined here

(set/define h a 1)
(set/define h a 2)
(hash-set! h 'b 42)

(define bar (make-hash))
(set/define bar a 1)

(define (foo)
  (set/define local-h a 1)
  (set/define local-h a 2)
  (hash-set! local-h 'b 42)
  local-h)

(foo)

Basically, if the identifier h is unbound at runtime
  (set/define h key val)
is the same as
 (define h (make-hash))
 (hash-set! h 'key val)

If h is bound
 (hash-set! h 'key val)

-- 
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] catch and bind an unbound id in a macro

[zeRusski]

On Friday, 19 April 2019 22:39:10 UTC+1, Michael Murdock MacLeod wrote:
>
> I'm in no ways a macro expert, but will this work? It uses 
> identifier-binding 
> to check if the identifier for the hash table is bound. 
>

Yep, looks like the winner. I should've inferred from the fact that 
"unbound identifier" is a compile time error that there must be a way to 
check said binding at compile time, sigh. Also, I only learnt that its a 
compile time error today and couldn't quite figure how the expander can be 
certain. Now I'm thinking, wait, all those syntax objects have sets of 
scopes attached for a reason.

-- 
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] catch and bind an unbound id in a macro

[zeRusski]

Matthias, FWIW your first solution gave me a flashback from last year's 
Summer School. I remember using this trick. Now I hope I don't forget when 
I actually need it.

Thank you Michael and 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] catch and bind an unbound id in a macro

[zeRusski]

Luke, thanks. You were the first to get there and somehow I missed your 
reply :(

On Friday, 19 April 2019 22:31:41 UTC+1, luke.whittlesey wrote:
>
> `identifier-binding` might be useful if a binding can be defined outside 
> of set/define
>
>
> https://docs.racket-lang.org/reference/stxcmp.html?q=identifier-binding#%28def._%28%28quote._~23~25kernel%29._identifier-binding%29%29
>
>>
>>

-- 
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] Inline tests for library and corresponding lang result in a loading cycle

[zeRusski]

> If you want to invoke the language as `#lang foo/bar` then you would put 
> this `reader` submodule in "foo/bar.rkt". This would make 
> "foo/bar/lang/reader.rkt" obsolete.
>

Duh. I think I understand how this resolves now and I have a flat 
structure, which I think works nicely:

foo*/:*
- main.rkt   [that simply reprovides bar.rkt and has a reader 
submodule with semantics in foo/bar-lang.rkt]
- foo.rkt [foo library]
- foo-lang.rkt [foo language semantics, just provides and exceptions]
- bar.rkt [bar library, but also has reader submodule with 
semantics in foo/bar-lang.rkt]
- bar-lang.rkt  [bar language semantics, just provides and exceptions]

Dunno if its the right way to do it, but all of the following seem to work 
now:
#lang foo
#lang foo/bar
(require foo)
(require foo/bar)

Thank you Matthew!

-- 
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: catch and bind an unbound id in a macro

[zeRusski]

On Saturday, 20 April 2019 23:55:50 UTC+1, Stephen Chang wrote:
>
> fwiw, I think here is a working version along the lines of your 
> original attempt. 
>

I see what you did there. This is both icky (as requested) and cute  :0 
Thanks, it's actually illuminating 

-- 
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] Being a good macro citizen: patterns to follow for good error reporting

[zeRusski]

I just had an epiphany, or rather a very painful revelation, that if your 
macro does not report errors in terms of user code, say, when inputs are 
wrong, you ought to be ostracized by the community if not banished from any 
social interactions altogether. You don't deserve the good life. Solitary 
confinement, damn it, until you've repented your sins, for you have sinned!

Every macro has a good path - one that lets us figure what it should expand 
into. I doubt I'm alone in merrily banging out said expansions without so 
much as a single thought about all the bad paths the macro can take. It's 
gotten painfully obvious lately, that if I don't take care to capture such 
erroneous states and expansions, my macro may as well be broken, as in 
completely wrong, even if it does the right thing for correct inputs.

Sadly, I don't think I have any systematic approach to being a good citizen 
here, nor is my mental model for syntax objects I produce has an entry for 
good locations and context. First, I noticed that I started to use 
syntax/loc in place of #' everywhere I produce syntax objects. Then more 
pain led me to discover a combination of ~describe pattern with #:context 
syntax-parse option. And, I tell ya they are MAGICAL! Both were learnt 
through hardship and pain, so I wonder if there is a compendium of patterns 
that I should be cognizant of to avoid at least some of that pain as I push 
Racket harder?

Could people maybe share relevant examples, or point out Racket machinery 
that may not be immediately relevant but one should have at least passing 
knowledge of to recognize when it may come in handy?

Is this too broad of a request?

-- 
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] How would you implement autoquoted atoms?

[zeRusski]

I must apologies for what follows will be more of a rambling than an 
exercise in clear thinking. That is because I am a bit stuck and thought 
I'd seek help.

I have been thinking some about languages and how it isn't always easy to 
clearly separate language being implemented from the language used to 
implement it. The picture gets particularly blurry in Lisps. This time 
around the question that gave me pause was one of implementing symbols. 
Better still Racket keywords, since like many lispy terms "symbol" has so 
many confusing meanings that its nigh impossible to tell what people mean 
exactly. I specifically talk about autoquoted datums. Two interned symbols 
that are equal? are eq?, two keywords that are equal? are eq?, 42 is eq? to 
42, etc. Symbols are bad example cause people often think about 'symbol or 
identifier with semantics being: perform variable lookup.

Someone on this list said everything in Racket is a struct, so lets start 
there.
 
 (struct kw (symbol))

We can also come up with some syntactic representation and extend our 
language with read and read-syntax that translate this new syntax into 
kw-struct as needed. But then we also demand that two syntactically equal 
kws end up being the same value in the language, so no matter where our 
reader encounters #kw(foo) it must produce the same value. This must be 
true across module boundaries, too. Just like Racket keywords. So, what are 
we to do? There's time when the reader runs, followed by expansion. Does 
this mean they need to communicate somehow? Also, the reader "runs", that 
is it is written in Racket (or some derivative) after all, but reader's 
environment isn't one where expansion happens, and that of the final code 
being evaled is different still. Right? 

To ensure eq? of two kws with the same printed representation we'll 
probably want to keep some global table around that keeps track of 
"interned" kws. So, for any two #kw(foo), our reader would have to produce 
something like (lookup-intern-kw  #:symbol 'foo), which at run-time would 
consult the table of kws and return the (kw 'foo) already there, or create 
a fresh entry and return that new struct. Two observations: (a) it follows 
that the global table is one that must exist at runtime - not while the 
reader runs, and (b) we end up relying on the host language for symbol 
equality after all 'foo is eq? 'foo and that allows us to key the table by 
symbols e.g. 'foo.

Is this how you would do it? Is there a better way that involves the reader 
more and relies on the runtime less?

Bonus question. What if we allow families of kws effectively partitioning 
kws into namespaces: #kw(family name). This appears a small variation of 
the above, where you'd simply assemble a compound symbol from family and 
name to use for the table lookup. That is until you allow parameterizing by 
"current-family", so kw declaration can omit the family part and it gets 
inserted as needed - not unreasonable in a language with modules or 
explicit namespaces. We could allow something like this:

#lang racket/kws
#:current-family addams

#kw(morticia)

now any kw within a module without family must translate into one of addams 
family. But also any #kw(addams morticia) in a different module must be eq? 
to the one above and in fact to any one like that anywhere. One exception 
is probably if we send them across Racket spaces which IIUC amount to 
running separate VMs. In the above example the reader would have to be 
aware of #:current-family declaration that may appear at the top of the 
module. We'd probably translate that to some (current-family 'addams) 
parameter setup, or wrap #%module-begin body in parameterize, then every kw 
without explicit family would have to check the (current-family) parameter. 

Is there a way to push this more to the read-time? If there is, what 
happens if we load the module and enter REPL? Could we ensure its reader is 
properly parameterized that it would use appropriate current-family?

How screwed up is my thinking here? Is there a way to leverage the reader 
more and rely on the runtime less? I imagine that'd make kws discussed 
lighter weight? We talk about phases some in Racket, but reader runs 
somewhere or rather sometime, too. I'd like to have a clearer picture in my 
head, I guess.

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.

[racket-users] How would you implement autoquoted atoms?

[zeRusski]

I must apologies for what follows will be more of a rambling than an 
exercise in clear thinking. That is because I am a bit stuck and thought 
I'd seek help.

I have been thinking some about languages and how it isn't always easy to 
clearly separate language being implemented from the language used to 
implement it. The picture gets particularly blurry in Lisps. This time 
around the question that gave me pause was one of implementing symbols. 
Better still Racket keywords, since like many lispy terms "symbol" has so 
many confusing meanings that its nigh impossible to tell what people mean 
exactly. I specifically talk about autoquoted datums. Two interned symbols 
that are equal? are eq?, two keywords that are equal? are eq?, 42 is eq? to 
42, etc. Symbols are bad example cause people often think about 'symbol or 
identifier with semantics being: perform variable lookup.

Someone on this list said everything in Racket is a struct, so lets start 
there.
 
 (struct kw (symbol))

We can also come up with some syntactic representation and extend our 
language with read and read-syntax that translate this new syntax into 
kw-struct as needed. But then we also demand that two syntactically equal 
kws end up being the same value in the language, so no matter where our 
reader encounters #kw(foo) it must produce the same value. This must be 
true across module boundaries, too. Just like Racket keywords. So, what are 
we to do? There's time when the reader runs, followed by expansion. Does 
this mean they need to communicate somehow? Also, the reader "runs", that 
is it is written in Racket (or some derivative) after all, but reader's 
environment isn't one where expansion happens, and that of the final code 
being evaled is different still. Right? 

To ensure eq? of two kws with the same printed representation we'll 
probably want to keep some global table around that keeps track of 
"interned" kws. So, for any two #kw(foo), our reader would have to produce 
something like (lookup-intern-kw  #:symbol 'foo), which at run-time would 
consult the table of kws and return the (kw 'foo) already there, or create 
a fresh entry and return that new struct. Two observations: (a) it follows 
that the global table is one that must exist at runtime - not while the 
reader runs, and (b) we end up relying on the host language for symbol 
equality after all 'foo is eq? 'foo and that allows us to key the table by 
symbols e.g. 'foo.

Is this how you would do it? Is there a better way that involves the reader 
more and relies on the runtime less?

Bonus question. What if we allow families of kws effectively partitioning 
kws into namespaces: #kw(family name). This appears a small variation of 
the above, where you'd simply assemble a compound symbol from family and 
name to use for the table lookup. That is until you allow parameterizing by 
"current-family", so kw declaration can omit the family part and it gets 
inserted as needed - not unreasonable in a language with modules or 
explicit namespaces. We could allow something like this:

#lang racket/kws
#:current-family addams

#kw(morticia)

now any kw within a module without family must translate into one of addams 
family. But also any #kw(addams morticia) in a different module must be eq? 
to the one above and in fact to any one like that anywhere. One exception 
is probably if we send them across Racket spaces which IIUC amount to 
running separate VMs. In the above example the reader would have to be 
aware of #:current-family declaration that may appear at the top of the 
module. We'd probably translate that to some (current-family 'addams) 
parameter setup, or wrap #%module-begin body in parameterize, then every kw 
without explicit family would have to check the (current-family) parameter. 

Is there a way to push this more to the read-time? If there is, what 
happens if we load the module and enter REPL? Could we ensure its reader is 
properly parameterized that it would use appropriate current-family?

How screwed up is my thinking here? Is there a way to leverage the reader 
more and rely on the runtime less? I imagine that'd make kws discussed 
lighter weight? We talk about phases some in Racket, but reader runs 
somewhere or rather sometime, too. I'd like to have a clearer picture in my 
head, I guess.

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.

[racket-users] Re: How would you implement autoquoted atoms?

[zeRusski]

One thought that only just occurred to me is that we certainly want to 
allow creating kws dynamically, so a piece of code may generate some. IIUC 
this means it can no longer be a purely reader-based feature. Either reader 
and runtime have to communicate the global table somehow or the entire 
thing belongs at runtime save for actually parsing text. I wonder how 
taxing such implementation becomes. I feel like Racket keywords and 
interned symbols may have some lower language support that I can't access?

-- 
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] How would you implement autoquoted atoms?

[zeRusski]

On Tuesday, 23 April 2019 15:57:52 UTC+1, Matthew Flatt wrote:
>
> This response will be rambling, too. :) 


And here I thought I asked an embarrassingly silly question :)

While implementing a "naive" version I ran into two issues that I kind of 
predicted upfront, but just wanted to make sure they indeed would present a 
problem:

#lang prelude/tags

(list 1 #k(foo) 2)
;; => (tag 'foo) as rewritten by our extended reader, 
;; where tag is a struct provided by prelude/tags

(begin-for-syntax
  (list 1 #k(foo) 2))
;; => ; tag: undefined;

This can be solved with (require (for-syntax prelude/tags)) but as with 
other autoquoted types I'd probably want to be able to just write them in 
any phase. Docs say some stuff about namespaces having a scope that crosses 
all phases plus separate scopes for each phase. Is there a way for a 
binding to span all phases without cooperation from the user?

Another problem is with REPL. Above runs fine when I run the module, but 
not if I type in REPL. 

scratch.rkt> (list 1 #k(foo))
; stdin::1273: read-syntax: bad syntax `#k`
; foo: undefined;
;  cannot reference an identifier before its definition
;   in module: "/Users/russki/Code/scratch.rkt"

What's up with that? Does the reader there need to be defined specially 
somehow?

I would be really happy to see someone experiment with these ideas, and 
> I'm pretty sure they could be implemented mostly by changing the 
> expander and reader in "racket/src/expander"


I'd love to see this implemented, but  Racket internals terrify me. As you 
can see above I can barely cope with the basics :)

-- 
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] how do you read, manipulate, debug scope sets?

[zeRusski]

I wrote a macro which introduced an implicit binding <~ so that it could be 
used
in expressions at the use-site. Initially did it with

#+begin_src racket
  ;; inside syntax-parse
  (datum->syntax this-syntax #'<~)
#+end_src

followed by macro introduced expr that binds it, then the use-site 
macro-input
that uses it. Think (let/ec <~ macro-input-body).

Worked just fine when tested at top-level or module begin or in expression
position, but then suddenly broke when I wrote another define-like macro 
whose
body expanded into the macro above. Turns out scopes of <~ at use-site and 
one I
introduced in a macro didn't match, at least that's what I surmount from the
message below. I was originally going to ask if someone could teach me to 
read
these messages, but then I found ~syntax-debug-info~ in docs :) and IIUC the
message below tells me there are two identifier bindings where the error 
occurs
whose scope-sets share some scopes namely "common scopes ...", but neither 
one's
scope-set is a subset of the other hence the error. Am I reading it right?

#+begin_src racket
; /Users/russki/Code/tilda/prelude/tilda.rkt:303:20: <~: unbound identifier
;   in: <~
;   context...:
;#(2212719 use-site) #(2212754 intdef) #(2212808 local)
;#(2212809 intdef) [common scopes]
;   other binding...:
;local
;#(2212718 macro) [common scopes]
;   common scopes...:
;#(2198084 module) #(2198091 module tilda) #(2212726 local)
;#(2212727 intdef) #(2212737 local) #(2212738 intdef) #(2212741 local)
;#(2212742 intdef) #(2212745 local) #(2212746 intdef) #(2212749 local)
;#(2212750 intdef) #(2212753 local)
#+end_src

I fixed the above with some guesswork that amounted to replacing 
datum->syntax
with

#+begin_src racket
  (syntax-local-introduce #'<~)
#+end_src

which IIUC simply flips the scopes so now <~ is use-site and may as well be 
part
of the macro input. Right?

Suddenly I find myself playing games with hygiene and not really knowing the
rules.

Are there any tutorials that show you how to use things documented in Syntax
Transformers chapter of the Reference?

How do you debug these scope games?

How do you introduce or capture identifier bindings (break hygiene)?

Can you temporarily unbind an identifier (for the extent of some expr), so
basically remove or trim some scopes from identifiers that occur in macro 
input? I
suppose there are several possible cases here: 
- trim or replace scopes of ids whose sets match those at use-site, 
guessing this
  won't unbind "shadowing" identifiers (let or define introduced in your 
macro
  input) i.e. those with extra scopes in addition to use-site,
- how do we deal with those, could we trim ids whose scope sets are 
supersets of
  use-site?
- assuming I know how to do the above, do I walk the syntax tree and trim 
those
  scopes every time I find matching id or is there a better way?

At this point I'd like to better understand how to manipulate sets of 
scopes and
verify the result. Could someone kindly teach me or point out good reads or
examples?

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] how do you read, manipulate, debug scope sets?

[zeRusski]

Thanks Matthew I'll have a look
>
>
All:
I published a link to the code I had in mind in a separate thread 
, so if 
interested check it out. I don't want to pollute this one if someone takes 
on the challenge of answering in more general terms.

-- 
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/43bf4832-e649-4e08-9151-7a02277ee4ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] tilda - a threading macro full of itself

[zeRusski]

I asked in a separate thread how one debugs set of scopes 
 in 
Racket macros. I appreciate the question may read a bit hand-wavy and 
abstract, so I split out the piece of code I had in mind into a separate 
package so that interested Racketeers could have a look and their time 
permitting maybe even suggest improvements.

Tilda is nothing but an opinionated threading macro. Even though 
"threading" macros punctuate all of my Clojure code I've been mostly making 
do without them in Racket. I was just being lazy tbh. I finally caved but 
instead of using off the shelf implementation I turned this into a nice 
exercise in macrology.

https://github.com/vkz/tilda

README shows off its capabilities with silly but hopefully sufficient 
examples.

If you have 5-10min on your hands and would like to help me learn, I'd 
appreciate PRs that improve or critique my code. Obviously, feel free to 
write here, but Github may provide a nicer interface to discuss code.

Also, see if you can break it:
- break scoping rules,
- hit an error that doesn't point to correct location with errortrace on 
etc.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/4f36682c-f2f4-44a2-89f7-55ee00b1151b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] tilda - a threading macro full of itself

[zeRusski]

>
> It just names the threaded value. Did I overlook anything?


That's right, nothing fancy. Think let-binding the threaded value at that 
point. #:with id ~ would achieve the same thing, so as it is now #:as is 
redundant. With #:do both #:with and #:as are redundant, really.
 

> Let me point out that if ~> specified an identifier (as suggested in my 
> first response) you could co-mingle two threaded computations, keeping 
> separate concerns that don’t matter as opposed to bundling them up in 
> structs or lists or whatever you have to do if you have only one. At first 
> I thought #:as would you let you do so, but that’s not correct.


Ok, this one I don't quite understand. My first thought went as far as to 
weave multiple computations where each #:as would capture continuations and 
macro would keep these "threads" separate, but now I'm thinking you mean 
this:

(~> 1 #:as ~a
;; now ~a is being threaded
(add1 ~a)   ;=> 2
2 #:as ~b
;; now ~b is being threaded
(add1 ~b)   ;=> 3
;; simply use whatever ~a was last
(+ ~a ~b)   ;=> 5
#:as ~a
;; continue to thread ~a
(add1 ~a)   ;=> 3
(list ~a ~b))
;; => (list 3 5)

but then I think you can achieve this with current #:as semantics since a 
clause without a hole simply starts computation from that clause yet 
preserves any #:as bound vars in scope, so I'm guessing I'm way off. Could 
you expand please? 

-- 
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/ad4b7d46-5b3f-42b4-b50d-019c786de63e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] tilda - a threading macro full of itself

[zeRusski]

>
> It just names the threaded value. Did I overlook anything?


That's right, nothing fancy. Think let-binding the threaded value at that 
point. #:with id ~ would achieve the same thing, so as it is now #:as is 
redundant. With #:do both #:with and #:as are redundant, really.
 

> Let me point out that if ~> specified an identifier (as suggested in my 
> first response) you could co-mingle two threaded computations, keeping 
> separate concerns that don’t matter as opposed to bundling them up in 
> structs or lists or whatever you have to do if you have only one. At first 
> I thought #:as would you let you do so, but that’s not correct.


Ok, this one I don't quite understand. My first thought went as far as to 
weave multiple computations where each #:as would capture continuations and 
macro would keep these "threads" separate, but now I'm thinking you mean 
this:

(~> 1 #:as ~a
;; now ~a is being threaded
(add1 ~a)   ;=> 2
2 #:as ~b
;; now ~b is being threaded
(add1 ~b)   ;=> 3
;; simply use whatever ~a was last
(+ ~a ~b)   ;=> 5
#:as ~a
;; continue to thread ~a
(add1 ~a)   ;=> 3
(list ~a ~b))
;; => (list 3 5)

but then I think you can achieve this with current #:as semantics since a 
clause without a hole simply starts computation from that clause yet 
preserves any #:as bound vars in scope, so I'm guessing I'm way off. Could 
you expand please? 

-- 
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/c580880e-6551-44c0-b144-79c32faaefe8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: tilda - a threading macro full of itself

[zeRusski]

> For example, it's better if a threading macro expands using the `#%app` 
> bound at the macro use site. (Whereas by default, macros expand using 
> identifiers bound where the macro is defined.) 
>
>   https://github.com/lexi-lambda/threading/issues/3 
>
>
Got this one right in the ~> macro, but not in define~>, nor in lambda~>. 
Thanks Greg, you totally nailed a bug ))
 

> Also you might want to treat `quote` forms specially, and not "thread 
> into" them. 
>
>   https://github.com/lexi-lambda/threading/issues/2 
>

This one is a non-issue since the macro disallows naked expressions, that 
is every clause is expected to be consistently wrapped in parens, and 
hole-markers either need to appear in the clause or the clause "re-strarts" 
the threading e.g. (~> ht 'x) is the same as (~> ht (quote x)) => 'x, since 
(quote x) has no marker, ht gets thrown out.

If you really want Clojure style hash-table accessor a-la keywords, 
assuming you have appropriate #%app in place, you'd write: (~> ht ('x ~)), 
that is you have to be explicit with your hole-markers.

-- 
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/f11fcf85-ae86-4670-88b1-694552ea5951%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: how do you read, manipulate, debug scope sets?

[zeRusski]

>
> #+begin_src racket
>   ;; inside syntax-parse
>   (datum->syntax this-syntax '<~)
> #+end_src
>
> Notice that the second argument to datum->syntax should be a symbol here, 
> rather than a syntax object. If you provide a syntax object as you did in 
> your original code, datum->syntax simply returns that syntax unchanged.
>

Damn, you totally caught it! Indeed, I was an idiot and used syntax where 
symbol was meant. Thank you
 

> I don't expect using syntax-local-introduce will work reliably; before the 
> change to the scope sets model of hygiene in Racket 6.3 it was another way 
> to accomplish this purpose, but no longer.  For example, it breaks when the 
> macro introducing the binding and its use are in different modules. Below, 
> (m introduced) works in a but fails in b.
>

And this totally makes sense now that, thanks to your example, I've seen 
the error msg its produced. Indeed, the two sets of scopes differ, so you 
end up with an unbound identifier there. Also confirmed with my own 
implementation and switched it back to datum->syntax as you suggested above 
and now escape with <~ works as expected. At least the error matches my 
mental model even if this means I no longer understand the purpose of 
syntax-local-introduce.

I think I ought to re-read the syntax model chapter in docs and read the 
papers you mentioned. Maybe even make it a regular exercise :)

Thank you Michael

-- 
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/0c308260-d39f-4e84-9629-c0dea14ba6f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] First class compound datatypes that can Racket

[zeRusski]

This would probably sound like rambling but that's only because I am 
struggling a
little bit. I implemented a little language that offers its own compound 
data
type: first class and users can extend it in various ways. Naturally, it is
implemented as a Racket struct. As I started using the language, it 
occurred to
me that I lost something and I'd very much like to get it back.

Racket struct offers some truly powerful machinery that permeates Racket
ecosystem. Here's a motivating example: having a new fancy first class 
compound
datatype (tm) is nice and well but what if I want it to double as a
synchronizable event? Oops. I do facilitate extensions, but that's 
something that
would need prop:evt on the underlying struct. I could "extend" my language 
and
add this prop myself, but it isn't a given that every instance needs to be 
an
event, not to mention there isn't "one size fits all" here, and the user 
may want
to customize the result of synchronization, if they even want events at 
all. More
generally though, how about other properties that may not even exist yet? Of
course I could surgically extend my implementation and allow to customize 
those
extensions etc. But that kind of opens pandora's box, not to mention most 
of the
time it'll simply be a "passthrough" of what Racket structs can already do, 
and
all of this nonsense would have to be documented - again why bother given 
the
marvel that is Racket documentation?

Conventional wisdom holds that you don't expose implementation details, but
honestly I'm ok dispensing with the dogma in this case. It isn't obvious to 
me how
to do that, though. Suppose, you derive a new stuct somehow: say, it 
implements
prop:evt but must otherwise be like your datatype. What does that mean? 
Struct
inheritance isn't that - I know that much. It must be a protocol of some 
kind - a
set of functions and what not (behaviors, really) that make your fancy 
datatype
what it is. One possible solution is Racket generics that is assuming we can
capture the essence of our type as a set of methods. Suppose for a moment, 
that we
could. While the underlying implementation may have changed and become 
either
richer or more constrained, it should still act as our fancy datatype. Since
Racket generics don't delegate to base types, are we to demand that the user
extends the interface to the struct that is nothing but a wrapper around 
another
struct that already implements said interface? That's asking too much IMO.

Is the answer to offer a macro that expands into something like

  (struct extended-type fancy-type () #:methods gen:fancy-iface ...) 

where I suspect fancy-iface methods don't need to change at all between 
macro
invocations?

This can't be a new problem. Any thoughts or advice?

-- 
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/c76a6178-8b8e-4032-aa2d-8430399365c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] First class compound datatypes that can Racket

[zeRusski]

>
> p.s. While you "have the hood open", you might also want to do something 
> similar for `prop:procedure`? 
>

I would agree that it is A solution to this particular problem with this
particular prop. The "passthrough" of some form or other works well and is 
always
open to me as the language maintainer but it amounts to special-casing 
things and
making me the sole arbiter of what makes it into the language and what 
doesn't.
Notice however that nothing about our fancy datatype changes, its interface
remains the same, yet user gets a richer type. Which means there ought to 
be a way
to generalize this. To use your analogy I'd like to find out if there's a 
way to
"leave the hood open" just enough or at least let the user do the 
"passthrough"
trick without the need to dismantle the entire car.

-- 
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/d76a37e0-8c49-4ac1-9aad-bdca3f91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Racket Mode documentation

[zeRusski]

this is pretty cool Greg! I, too, had a brief excursion into documenting 
with Org. It still needs work, but here is an org-source 
 that 
can be executed to generate the REAME.org 
 (or whatever other 
format you need) suitable for Github. Some brownie points of this approach: 

- extracts reference documentation from Elisp docstrings (your code does 
something similar me thinks),
- lets you interleave whatever text or examples you want, 
- collects all examples in the same file and runs them in ERT deftest,
- code that does all that leaves in source blocks in the same Org-file, so 
basically everything is just one file.

Curiously, this could be a pan-lingua approach, suitable for any proglang, 
not just Elisp. Maybe with some work, perhaps with some extra work if your 
language doesn't play nicely with Org Babel or whatever. Org is amazing. I 
think it should marry Scribble and procreate ))


-- 
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/f96c932a-27a7-42b5-bba5-fad013170b61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Racket Mode documentation

[zeRusski]

this is pretty cool Greg! I, too, had a brief excursion into documenting 
with Org. It still needs work, but here is an org-source 
 that 
can be executed to generate the REAME.org 
 (or whatever other 
format you need) suitable for Github. Some brownie points of this approach: 

- extracts reference documentation from Elisp docstrings (your code does 
something similar me thinks),
- lets you interleave whatever text or examples you want, 
- collects all examples in the same file and runs them in ERT deftest,
- code that does all that leaves in source blocks in the same Org-file, so 
basically everything is just one file.

Curiously, this could be a pan-lingua approach, suitable for any proglang, 
not just Elisp. Maybe with some work, perhaps with some extra work if your 
language doesn't play nicely with Org Babel or whatever. Org is amazing. I 
think it should marry Scribble and procreate ))


-- 
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/213ed175-06a9-44c1-ba40-e8f5e5f0bc9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Mutating hash-map while iterating

[zeRusski]

Is it ok to mutate a hash while iterating over it say in one of ~for~ forms?
Specifically I want to filter (that is drop) some keys, but I'm also 
interested in
mutation in general. I guess the answer lies in whether forms like 
~in-dict~ etc
create lazy streams that hold on to the table?

Relevant docs that I managed to dig out: 
- hash-map 

 
seems to suggest that at least dropping keys is fine, but that only
  talks about hash-map procedure specifically not other forms;
- caveats concerning concurrent modifications 

 
maybe kinda relevant (I've asked 

  similar question about concurrency 

 
some time ago).

Here're some examples to be concrete:

#+begin_src racket
  ;; IMO ok according to docs?
  (hash-map h (λ (k v) (when (pred v) (hash-remove! h k

  ;; probably ok assuming it translates to hash-map?
  (dict-map h (λ (k v) (when (pred v) (dict-remove! h k

  ;; is that ok?
  (for (((k v) (in-dict h))
#:when (pred v))
(dict-remove! h k))

  ;; defensive solution
  (let ((fails (for/list (((k v) (in-dict h))
  #:when (pred v))
 k)))
(for-each (curry dict-remove! h) fails))
#+end_src

That question wouldn't arise were I to deal with immutable data, but I'm 
not.

-- 
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/b57fc367-64b3-434b-93bb-ddb0684d26fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: New Package: Dynamic FFI - Write C Code Inline

[zeRusski]

Oh wow! IIUC it is super awesome. Would a natural next step be #lang terra 
?
Hey Jay McCarthy would you like to mentor that effort ;-)


On Saturday, 1 June 2019 20:06:29 UTC+1, David Benoit wrote:
>
> Hi All,
>
> I've recently released a new library 
>  for dynamically 
> generating FFI bindings to C by parsing header files.
> It also allows users to create FFI libraries by writing C functions 
> directly inline in Racket programs.  
>
> The library works as a native extension to Racket by linking with Clang's 
> parser libraries and converting AST declarations into FFI objects.
> As a result, the package depends on Clang and LLVM headers and libraries.  
> See the documentation 
>  for info on 
> installing dependencies.
>
> I've only built the package on GNU/Linux so far.  If anyone is interested 
> in building the library on other OSes, it should be a fairly trivial port.
>
> I'd like to give a special thanks to Jay McCarthy, who came up with the 
> idea for this project and was my adviser during its implementation.
> I hope its something the Racket community might find useful!
>
> More usage examples are available in the docs and the test directory 
>  in the source 
> code.
>
> Thanks!
> David B
>
> I'll sign off with a quick preview:
>
> #lang at-exp racket/base
>
> (require dynamic-ffi/unsafe)
>
> @define-inline-ffi[struct-test]{
>   #include 
>   #include 
>   #include 
>
>   typedef struct {
> char *name;
> uint64_t value;
>   } number;
>
>   char* names[] = {"zero", "one", "two", "three", "four", "five", "six"
>  "seven", "eight", "nine", "ten", "eleven", "twelve"};
>
>   number add(number a, number b) {
> number c;
> c.value = a.value + b.value;
> if (c.value >12)  {
>   fprintf(stderr, "error: this example can only count to twelve...\n");
>   exit(1);
> }
> c.name = names[c.value];
> return c;
>  }
> }
>
> ;; _list-structs are created by default.  I hope to optimize this in the 
> future.
>
> (define n2 (list "two" 2))
>
> (define n7 (list "seven" 7))
>
> (printf "add(n2, n2): ~a\n" (struct-test 'add n2 n2))  ;; output: add(n2, 
> n2): (four 4)
> (printf "add(n7, n7): ~a\n" (struct-test 'add n7 n7))  ;; output: error: this 
> example can only count to twelve...
>
>
>
>
>
>

-- 
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/628bf864-d261-481b-962c-2e54be297228%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Mutating hash-map while iterating

[zeRusski]

Thank you Ben. That answers my question. About what I expected - be 
defensive when in doubt.

On Monday, 3 June 2019 19:07:44 UTC+1, Ben Greenman wrote:
>
> You want the paragraph just above the caveat about concurrent 
> modification: 
>
> > A hash table can be used as a two-valued sequence (see Sequences). The 
> keys 
> > and values of the hash table serve as elements of the sequence (i.e., 
> each 
> > element is a key and its associated value). If a mapping is added to or 
> > removed from the hash table during iteration, then an iteration step may 
> fail 
> > with exn:fail:contract, or the iteration may skip or duplicate keys and 
> > values. See also in-hash, in-hash-keys, in-hash-values, and 
> in-hash-pairs. 
>
> https://docs.racket-lang.org/reference/hashtables.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/bce03cf0-5283-43a5-80ef-469a5794c340%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: [ann] marionette: control Firefox from Racket

[zeRusski]

Brilliant! Thank you for this

-- 
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/f258c49e-838a-4013-b730-172beabf4024%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: grammar-based fuzzing

[zeRusski]

cool wasn't aware of Xsmith! Surprised to find RACR backing it - I looked 
at its source a while back for some attribute grammar magic - ended up not 
doing anything though - was it lack of docs - can't recall. IIRC it has 
some true scheme magic in there.

Academics often suck at marketing ;) For those who, like me, were 
interested but failed to navigate to relevant bits:
- Xsmith docs: https://docs.racket-lang.org/xsmith/index.html
- Xsmith src: https://gitlab.flux.utah.edu/xsmith/xsmith
- RACR docs: 
https://github.com/christoff-buerger/racr/blob/master/racr/documentation/contents.md
- RACR src: https://github.com/christoff-buerger/racr

On Thursday, 6 June 2019 21:41:21 UTC+1, Eric Eide wrote:
>
> Ryan Kramer > writes: 
>
> > Does Racket have any grammar-based fuzzing utilities? 
>
> You might be interested in Xsmith.  Version 1.0 will be released 
> imminently, 
> like within the next week.  I'll send another email when it's released. 
>
> Stay tuned! 
>
> -- 
> ---
>  
>
> Eric Eide >  . University of Utah 
> School of Computing 
> http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 
> 581-5843 FAX 
>

-- 
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/f46560e1-2f64-499f-96a1-c4ac0e465a1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Impromptu racket meetup in London Friday, 19 July at 12pm-3pm

[zeRusski]

argh, wish you'd go with after work hours or the weekend. Sorry, won't be 
able to make it.

On Friday, 12 July 2019 09:20:58 UTC-6, Stephen De Gabrielle wrote:
>
> Hi,
>
> Next Friday, 19 July at 12pm-3pm there will be an impromptu Racket meetup 
> at the cafe at the British Library 'The Last Word'. 
> https://goo.gl/maps/M62e4b9JK7c1oaA69 
>
> No agenda. All welcome. Spread the word!
>
> I'll be drinking tea, eating cake(I hope), and will be easily identified 
> as a the man with racket logo on his laptop. Updates on this thread.
>
> Stephen
>
>

-- 
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/08648123-28e8-46ff-9bf8-20f0cb11d1dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Strange Loop talk about Racket is up

[zeRusski]

https://youtu.be/yU-HUb8Xykg

I'd estimate 10-15min total overlaps with my RacketCon talk here and there, 
25-30min is my take on metaprogramming, Lisps and, of course, Racket. 
Haven't watched it myself, yet - need some hard liquor to numb the pain of 
listening to ones own voice :)

-- 
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/7df34d8d-c18a-4164-8ce3-e7abfe86d63c%40googlegroups.com.

[racket-users] Embedding Racket CS

[zeRusski]

How I might go about embedding Racket CS in a fairly big C codebase, about 
100KLOC big. It is exceptionally well written C authored by people who knew 
what they were doing. I am sadly not one such person, so I'd rather not 
muddy things with my exceptionally terrible C. C code will be driving the 
whole application, which means it'll be the one to call into Racket. Since 
I'd rather not re-implement the whole thing in Racket I'd probably have it 
call back into C for the things implemented there, so I'll have to program 
Racket bindings for at least the things I care in the C library. That's the 
task at hand.

I managed to embed Gambit so I can now have my nested call bonanza: C 
initializes Scheme, invokes Scheme procedures some of which call back into 
C etc. Gambit makes it mostly straightforward. I can certainly make do with 
Gambit, but it'd be nice to have access to Racket batteries, its macro 
bazooka and, you know, actual documentation, so I am eager to try. I 
imagine it'll be quite the workout with CS. I am specifically interested in 
doing this with Chez version, not the C API of the main system, unless our 
plan is to offer the same FFI in Racket CS.

Looking at racket/src/cs/Makefile it builds racket.so, which I suppose I 
can link. It wouldn't offer anything in terms of C FFI yet, right? But I 
bet it links Chez. I wonder if I could lean on its C API which Chez docs 
make out to be nice enough. I could maybe wrap the C API I care about in a 
Chez library, compile and link it, then compile and load Racket user code 
that calls the wrapper compiled from Scheme? Would that be hard? How chummy 
is Racket with Chez, really? Is indirection through Chez the way to go atm?

Is there a more straightforward way to embed Racket and have it as an 
extension language?

Have I wondered into "keep out unless Matthew" territory?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/156514ed-cae3-4cb4-8768-97be8c88c16c%40googlegroups.com.

Re: [racket-users] Embedding Racket CS

[zeRusski]

Failed so far, sigh.

First, CS snapshots in Utah and NW mirrors offer no libracketcs.a so I went 
ahead and attempted to build CS from the github master. Sadly its `raco` 
tool is unaware of the `ctool` subcommand, so I'm guessing snapshots are 
built from your own private fork or something. I then started mixing and 
matching stuff from snapshot and freshly built github:
- raco, boot files and headers from the snapshot,
- libracketcs.a from github

Am I doing this C thing wrong? :) Compiling modules with `raco ctool` 
worked fine. Linking against `libracketcs.a` however failed with a bunch of 
unresolved symbols like e.g. `CFLocaleCopyCurrent` most of them referenced 
from `rktio_convert.o`. It wouldn't work anyway since `declare_modules` 
also failed to resolve and I'm guessing I really need the `libracketcs.a` 
from the snapshot for that.

Another, probably unrelated issue where I'm likely not using the right 
incantation is linking in Racket.framework. Even with -F path supplied as 
needed `-framework racket` wasn't found. `man ld` for my platform shows it 
expects to find (in our case) Racket under Racket.framework so 
Racket.framework/Racket but all the frameworks you ship have intermediate 
dirs Version/blabla/Racket. I just copied Racket and boot/ under 
Racket.framework there to shut the linker up. Am I doing it wrong?

https://www.cs.utah.edu/plt/snapshots/current/doc/inside/cs.html is atm 
quite about calling C. Is it possible or at least in the cards? I'd like to 
use the API defined in C from Racket.

Thank you Matthew!

On Friday, 27 March 2020 22:53:42 UTC, Matthew Flatt wrote:
>
> At Fri, 27 Mar 2020 15:48:13 -0700 (PDT), zeRusski wrote: 
> > How I might go about embedding Racket CS 
>
> The current development version (as reflected by snapshot builds) now 
> has support and documentation for that: 
>
>  
> https://www.cs.utah.edu/plt/snapshots/current/doc/inside/cs-embedding.html 
>
> Of course, let me know if you run into any problems. 
>
>
> Matthew 
>
>

-- 
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/2ae01377-c89e-42ca-8ef9-dd1087da97d4%40googlegroups.com.

Re: [racket-users] Embedding Racket CS

[zeRusski]

>
>  It wouldn't work anyway since `declare_modules` also failed to resolve 
> and I'm guessing I really need the `libracketcs.a` from the snapshot for 
> that.
>

Oh ... I see `declare_modules` is produced by `raco ctool`. Why static 
though? This means I have to #include "hello.c" like in the example in the 
docs, but hm. At least I know why I was missing this particular symbol. The 
C codebase in question uses opinionated build tools e.g. `makeheaders` 
which analyses .c sources and produces corresponding header files, so 
anything static never makes into that hello.h which I tried to include.

 

>
> On Friday, 27 March 2020 22:53:42 UTC, Matthew Flatt wrote:
>>
>> At Fri, 27 Mar 2020 15:48:13 -0700 (PDT), zeRusski wrote: 
>> > How I might go about embedding Racket CS 
>>
>> The current development version (as reflected by snapshot builds) now 
>> has support and documentation for that: 
>>
>>  
>> https://www.cs.utah.edu/plt/snapshots/current/doc/inside/cs-embedding.html 
>>
>> Of course, let me know if you run into any problems. 
>>
>>
>> Matthew 
>>
>>

-- 
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/8b500094-3aeb-47f8-93f1-b88be1168147%40googlegroups.com.

Re: [racket-users] Embedding Racket CS

[zeRusski]

successfully called Racket CS from C. I'll try what you suggest re calling 
C from Racket at some point and report any problems.

Thank you!

On Sunday, 29 March 2020 21:41:46 UTC+1, Matthew Flatt wrote:
>
> At Sun, 29 Mar 2020 13:13:08 -0700 (PDT), zeRusski wrote: 
> > First, CS snapshots in Utah and NW mirrors offer no libracketcs.a so I 
> went 
> > ahead and attempted to build CS from the github master. Sadly its `raco` 
> > tool is unaware of the `ctool` subcommand, so I'm guessing snapshots are 
> > built from your own private fork or something. 
>
> Snapshot builds use the public GitHub repo's master. 
>
> `raco ctool` is provided by the "cext-lib" package. That package is 
> part of "main-distribution", but maybe you installed a subset of 
> packages when building? 
>
> > I then started mixing and 
> > matching stuff from snapshot and freshly built github: 
> > - raco, boot files and headers from the snapshot, 
> > - libracketcs.a from github 
>
> That could work. 
>
> > Linking against `libracketcs.a` however failed with a bunch of 
> > unresolved symbols like e.g. `CFLocaleCopyCurrent` most of them 
> referenced 
> > from `rktio_convert.o`. 
>
> You will need to link to some standard libraries and frameworks on Mac 
> OS: `-framework CoreFoundation`, `-liconv`, and `-lncurses`. 
>
> I didn't try to write this down because it varies so much across 
> platforms, and I expect C programmers to just know. :) But it should be 
> written down or made more automatic. 
>
> > It wouldn't work anyway since `declare_modules` 
> > also failed to resolve and I'm guessing I really need the 
> `libracketcs.a` 
> > from the snapshot for that. 
>
> `declare_modules` should be defined in the file generated by `raco 
> ctool --c-mods`. 
>
> > Another, probably unrelated issue where I'm likely not using the right 
> > incantation is linking in Racket.framework. Even with -F path supplied 
> as 
> > needed `-framework racket` wasn't found. `man ld` for my platform shows 
> it 
> > expects to find (in our case) Racket under Racket.framework so 
> > Racket.framework/Racket but all the frameworks you ship have 
> intermediate 
> > dirs Version/blabla/Racket. I just copied Racket and boot/ under 
> > Racket.framework there to shut the linker up. Am I doing it wrong? 
>
> A better strategy may be to use `install_name_tool` to update the 
> framework reference to be relative to the executable: 
>
>   install_name_tool -change \ 
>   "Racket.framework/Versions/7.6.0.18_CS/Racket" \ 
>   
> "@excutable_path/rel/to/Racket.framework/Versions/7.6.0.18_CS/Racket" \ 
>   path_to_your_executable 
>
> I don't know of a flag to the linker that will do this in the first 
> place. 
>
> > https://www.cs.utah.edu/plt/snapshots/current/doc/inside/cs.html is atm 
> > quite about calling C. Is it possible or at least in the cards? I'd like 
> to 
> > use the API defined in C from Racket. 
>
> Calling C from Racket is mostly left to the FFI documentation: 
>
>   https://docs.racket-lang.org/foreign/index.html 
>
> So, if you link your executable in such a way that `(get-ffi-obj name 
> #f )` can find the functions, then that's all you need. 
>
>
> There's also a way to publish C functions to make them visible at the 
> Chez Scheme level: 
>
>  https://cisco.github.io/ChezScheme/csug9.5/foreign.html#./foreign:s272 
>
> Then you'd have to propagate that to the Racket level somehow --- maybe 
> by using `vm-eval` from `ffi/unsafe/vm` to access Chez Scheme directly 
> on the Racket side. I haven't given that much thought, so far. 
>
>

-- 
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/743f1f10-cf27-4e24-a43e-6cf56c52049c%40googlegroups.com.

[racket-users] How to run multiple Racket installations?

[zeRusski]

I have two builds of Racket on my local machine. Racket CS resides in one 
directory and was built with `RACKETCS_SUFFIX=""` and stardard Racket also 
built from source in a separate directory. Normally I have my .bashrc setup 
PATH as needed to use e.g. Racket CS. I ran into a problem with an upstream 
package which maybe FFI related, so now I want to test it against standard 
Racket build so I switch over the PATH and run it with non-cs `raco` and 
`racket`.

First, does that even work? I noticed that both of them install packages 
into ~/Library/Racket/development/ for me. Are both builds so compatible I 
don't need to worry about packages stepping on each others toes i.e. 
compiled with one but executed with the other? I think I'd rather have the 
two systems completely separated so I can actually compare oranges to 
oranges. Is there a way to guarantee that? I don't have a mental model of 
having two builds like this.

How do you run and test multiple builds? Is there a good setup I can steal 
please?
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/195b0260-19f2-45b2-a36d-4edc344fef87%40googlegroups.com.

[racket-users] How to avoid all packages when building from source?

[zeRusski]

I just rebuilt Racket from git repo checkout. It takes a while but most of 
that time is spent in `raco setup` which appears to be building all 
packages in existence. E.g. games, redex-examples, realm of Racket chapter 
6 (really?), plai, algol, etc. Why do I end up with the entire jungle? Is 
there a way to avoid all these packages? Is there a way to figure where 
these dependencies are coming from?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/869f4d10-eb3a-42c1-a239-d71cdbc10092%40googlegroups.com.

Re: [racket-users] How to avoid all packages when building from source?

[zeRusski]

> You can do "make base" instead, which installs no packages. Or you can do 
> something like 'make PKGS=drracket' which just installs DrRacket and 
> dependencies, or similar with other packages. 
>

I am installing in-place but racket cs, not racket bc, so IIUC `make base` 
isn't what I want. PKGS confuses me a bit at least having read both the 
build.md notes and your comment. From the build notes I understand it 
controls what gets build (or linked in place) that's already in racket/pkgs 
dir - that would be the packages that are being developed alongside racket 
in the same repository. But then the notes say that PKGS defaults to the 
main-distribution like you said and apparently that brings in stuff beyond 
the racket/pkgs dir. I guess I can run with PKGS="" and see if indeed the 
racket/pkgs are still being built and linked, cause I really want them to. 
They are the ones I'd consider base.

-- 
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/ca77a5fd-2718-4b11-9cb8-6ed00f719d2c%40googlegroups.com.

[racket-users] Replace pre-installed rackunit with git source

[zeRusski]

Hi all. Latest commit to rackunit haven't made it into 7.7 so I attempted 
to replace the rackunit installed as part of the distribution in 
racket/share/pkgs by cloning the repo then:
  cd rackunit
  raco pkg update --force --type dir

  raco pkg show
would show the `rackunit` linked as expected, but the pre-installed looked 
like any require would still go to share/pkgs. Not sure why. Btw is there 
some API call to check which file was used to find a module?

Tbh having read racket/build.md - section 3.2 I expected this to just work. 
Perhaps I misunderstood it. I thought `extra-pkgs` dir wasn't anything 
special.

I then tried to remove the link, then remove the preinstalled 
share/pkg/rackunit-*, then link from local checkout again
  raco pkg remove --force rackunit-doc rackunit-test rackunit-typed 
rackunit-gui etc
  cd rackunit
  raco pkg install

Now any setup steps appear to fail complaining:
  module path: rackunit
  path: /Users/russki/Code/racket-cs/pkgs/racket-index/rackunit/main.rkt

Is this some docs index missing rackunit deps?

Is there a way to repair my racket installation and have rackunit linked 
from source? Or should I just wipe racket and start over?

-- 
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/62196fc3-d2d6-4ac4-8d70-7b38d068027do%40googlegroups.com.

Re: [racket-users] Replace pre-installed rackunit with git source

[zeRusski]

Sam thank you. Your suggestions mostly worked. At least I was able to 
unbork my installation. Steps taken:
- install the regular `rackunit`
⇒ still reported a bunch of errors re missing typet/rackunit
- raco pkg update --clone extra-pkgs/rackunit
⇒ took its sweet time, also produce similar errors

Code runs and appear to pull the right rackunit collection and I no longer 
see "regular" rackunit-* inside share/pkgs.

Now about that typed/rackunit module that other dependents fail to locate. 
That's def part of rackunit repo which is installed as cloned and indeed 
rackunit/rackunit-typed declare itself as part of the `typed` collection, 
so `typed/rackunit` should be available and yet:
- raco fc -i typed/rackunit
⇒ fails to find it

Not a blocker for me but somewhat surprising.

Thank you again for your help Sam. 
Ditto Ben Greenman

On Wednesday, 22 July 2020 19:09:46 UTC+1, Sam Tobin-Hochstadt wrote:
>
> To figure out where things are, I recommend the `raco fc` command, 
> which is in the `raco-find-collection` package. 
>
> Almost certainly what went wrong is that you installed the cloned 
> `rackunit` directory as a package. Instead, you need to install all 
> the individual sub-directories as packages. To fix that, first remove 
> the installed `rackunit` package, and then just re-install the regular 
> `rackunit`. 
>
> To accomplish your original goal, you should use `raco pkg update 
> --clone rackunit` in whatever directory you want to clone rackunit 
> (such as `extra-pkgs`). If that complains about `rackunit` not having 
> a git repository as source, then you should first do `racket pkg 
> update --lookup --catalog https://pkgs.racket-lang.org rackunit` to 
> switch from the 7.7 catalog to the pkgs.racket-lang.org one. 
>
> Sam 
>
> On Wed, Jul 22, 2020 at 9:03 AM zeRusski  > wrote: 
> > 
> > Hi all. Latest commit to rackunit haven't made it into 7.7 so I 
> attempted to replace the rackunit installed as part of the distribution in 
> racket/share/pkgs by cloning the repo then: 
> >   cd rackunit 
> >   raco pkg update --force --type dir 
> > 
> >   raco pkg show 
> > would show the `rackunit` linked as expected, but the pre-installed 
> looked like any require would still go to share/pkgs. Not sure why. Btw is 
> there some API call to check which file was used to find a module? 
> > 
> > Tbh having read racket/build.md - section 3.2 I expected this to just 
> work. Perhaps I misunderstood it. I thought `extra-pkgs` dir wasn't 
> anything special. 
> > 
> > I then tried to remove the link, then remove the preinstalled 
> share/pkg/rackunit-*, then link from local checkout again 
> >   raco pkg remove --force rackunit-doc rackunit-test rackunit-typed 
> rackunit-gui etc 
> >   cd rackunit 
> >   raco pkg install 
> > 
> > Now any setup steps appear to fail complaining: 
> >   module path: rackunit 
> >   path: /Users/russki/Code/racket-cs/pkgs/racket-index/rackunit/main.rkt 
> > 
> > Is this some docs index missing rackunit deps? 
> > 
> > Is there a way to repair my racket installation and have rackunit linked 
> from source? Or should I just wipe racket and start over? 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/62196fc3-d2d6-4ac4-8d70-7b38d068027do%40googlegroups.com.
>  
>
>

-- 
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/ad58815c-12b5-4360-8d9e-10b2e9e5af81o%40googlegroups.com.

[racket-users] Does Racket interpreter exist?

[zeRusski]

Hi all. I wonder if such a thing exist or even possible? Question triggered 
by the trade off between "compile slowly now to run fast later" vs "start 
fast". Racket like other modern(ish) Scheme derivatives appear to have 
settled on being in the former camp. Is there anything in the language that 
would make interpretation infeasible (semantics?) or unreasonably slow 
(expansion?)? Chez sports an interpreter with some limitations. I think 
Gambit ships one although I'm not sure how performant that one is. IIRC 
Guile recently got something. What about Racket?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/dd9dd201-5826-4453-8fbe-babc0c477dcdo%40googlegroups.com.

Re: [racket-users] Does Racket interpreter exist?

[zeRusski]

Thank you for this fantastic reply Sam! I now think I had a very naive 
model of "interpreter" when I asked the question. My CS degree from the 
nowhere university has it that language interpreters walk the tree and you 
know "execute" be it in the host language or generating native code. I feel 
a bit stupid now. Technically you're absolutely right - there is an 
interpreter for the bytecode (or whatever), so duh. But there are also a 
bunch of compilation steps in between. I am now completely lost as to what 
constitutes a compiler and what makes an interpreter. I always thought of 
interpreters as something I encountered in PLAI. I remember reading some 
old paper abound "fast interpreters" and all of them implemented a virtual 
machine they "compiled" to and I was lost then - how's that not a compiler 
- as I am lost now.

-- 
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/b183ae65-524d-4e70-9bee-ce0531bf21feo%40googlegroups.com.

Re: [racket-users] Does Racket interpreter exist?

[zeRusski]

>
> The best way to distinguish compilers from interpreters is that a 
> compiler takes a program and produces another program, whereas an 
> interpreter takes a program (along with some input) and produces an 
> answer. 
>

Doesn't this trivialize the difference a bit too much? Does it really come 
down to the time you choose to compute? I persist intermediate state - I am 
a compiler. I do the exact same thing (run off the same "compiler" 
codebase) but ask for inputs and compute - I am an interpreter.

I scratched my head a bit and came up with the following: if there is one 
to one correspondence between target and host language "blocks" (there may 
be multiple such pairs till you get to machine code) then this is an 
interpreter. If you do nasty shenanigans in the generated code in the host 
(semantics altering optimisation passes and what not) then this is a 
compiler. Latter ought to effect debugging even error reporting quite 
drastically. This is almost certainly naive and amateur of me. I'm 
desperately trying to understand why I have the impression that there ought 
to be a non-trivial difference between the two. That's been my impression 
from the literature.

I think I had this paper in mind: https://www.jilp.org/vol5/v5paper12.pdf 
oh wait p4: "we do not have a precise definition for efficient interpreter" 
... oh good. Although they do mention some justification for "compiling" to 
a VM in the following paragraphs that boils down to "avoid the overhead of 
re-parsing and re-interpreting intermediate representation". I vaguely 
recall that Lisp in Small Pieces switched to a VM when the "fast 
interpretation" was introduced.

I may have confused myself. Badly :(

I guess I would call Tcl and Picolisp interpreters and Racket and most 
Scheme implementations of note not at all.

-- 
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/98a4e936-1703-4182-bb85-ce78a8694feao%40googlegroups.com.

Re: [racket-users] Does Racket interpreter exist?

[zeRusski]

This is a really cool piece of history! Thank you.

I'll admit I'm somewhat fuzzy here - it maybe a bit too meta for me or 
perhaps I don't quite understand what you're trying to say. Isn't 
interpreting n levels deep also linear in n? Only difference between the 
two approaches  I see is that compiler lets you persist the fruits of its 
labor so you don't have to start from scratch every time. Couldn't you 
accommodate this with an interpreter (with some effort) although at this 
point it becomes a compiler I suppose. Definitely fuzzy here.
 

> But when going n levels deep, the total execution time with a compiler 
> is linear in n, and with an interpreter it's exponential. 
>
> That makes interpreting interpreters impractical when n gets large (even 
> with n around 3 or 4); whereas compiling compilers can be done even for 
> larger n. 
>

-- 
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/2f288d86-d90c-4881-b001-389b580fece8o%40googlegroups.com.

Re: [racket-users] Does Racket interpreter exist?

[zeRusski]

>
> -- hendrik 
>
> I hope this set of answers clarifies the distinction between an 
> interpeter and compiler, how the distinction gets blurred in practice, 
> and what the criteria are for choosng between them. 
>

This was both detailed, insightful and truly helpful. I can't thank you 
enough for taking the time Hendrik! I'm glad I pressed the matter.

Thank you

-- 
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/e1516c80-e082-4860-93c0-2ef27072987bo%40googlegroups.com.

Re: [racket-users] Does Racket interpreter exist?

[zeRusski]

Thank you Arthur. Indeed Lisp in Small Pieces cites this paper in the 
chapter about fast interpreters among two others but sadly in French :)

On Thursday, 30 July 2020 15:45:01 UTC+1, Arthur Nunes-Harwitt wrote:
>
> Hi, 
>
>While you're enumerating these possibilities, I think it's worthwhile 
> to 
> mention a technique related to the FORTH implementation technique: Marc 
> Feeley style compilation (see "Using Closures For Code Generation" in 
> Computer Language Vol 12 No 1 pages 47-66). This idea is also mentioned in 
> SICP. 
>

-- 
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/569aa81d-3ba4-49a3-8d44-7d005cebcae6o%40googlegroups.com.