Re: [racket-users] Is it necessary to print after expansion?

[jackhfirth]

>
> Still, because I'm writing for people new to Racket, I think it's wiser to 
> promote a habit of explicitly calling an output function. Why? Because as 
> you move code around, you may be surprised when something stops printing 
> (because it's no longer at the top level). For instance, new Racketeers 
> might be confused as to why the output of this program:
>
> #lang racket
> 1
> (begin
>   2
>   3)
> (let ()
>   4
>   5)
>
> is this (4 is not printed):
>
> 1
> 2
> 3
> 5
>

This honestly makes me wish that `let` *required* that expressions other 
than the last one produced `void`. Far too often it's a sign that 
something's wrong, usually because of misplaced parentheses. If an 
expression that would normally produce a value is being evaluated only for 
a side effect I'd rather explicitly call that out by requiring it be 
wrapped in a `(void _)` call.

-- 
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] Interning custom types?

[jackhfirth]

If I wanted to make my own interned data type, how hard would that be? I 
have a datatype representing an immutable sorted set of keywords and I want 
to guarantee that total memory use for these sets depends only on the 
number of unique combinations of keywords created by a program.

-- 
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: Pretty display of tabular data?

[jackhfirth]

Hooray! Now we're up to 7 tagged packages 
 (that was fast!)

On Saturday, March 16, 2019 at 12:13:38 PM UTC-7, johnbclements wrote:
>
> Yep, excellent idea. I’ve added the ’tabular’ tag to csv-writing. 
>
> John 
>
> > On Mar 15, 2019, at 3:24 AM, jackh...@gmail.com  wrote: 
> > 
> > I think we should all work towards making our existing code in this area 
> more discoverable, so we can get a better sense of what libraries for 
> working with tables exist in the wild. To those of you who own Racket 
> packages that provide any functionality related to data tables: I recommend 
> adding the "tabular" tag to your package's description in the package 
> catalog. There's no need to remove more-specific tags (like "data-frame") 
> from your package, but even if you have a more specific tag please include 
> the general "tabular" tag so it's easy to search for your package. So far 
> there's only 3 packages tagged with "tabular" (and one of those is a 
> package of mine that I just tagged while writing this post). I see several 
> packages that are good candidates for the tag: 
> > • data-frame 
> > • sqlite-table 
> > • table-panel 
> > • tabular 
> > • rml-core (maybe?) 
> > • sinbad 
> > • spmatrix (maybe?) 
> > • spreadsheet-editor 
> > • csv 
> > • csv-reading 
> > • csv-writing 
> > • simple-csv 
> > • Most things with the "sql" tag 
> > The more packages we have tagged and documented, the easier it will be 
> to find real code using tables in the wild. Which is information we'll need 
> if we want to understand how a standard `racket/table` API might look. 
> > 
> > On Thursday, March 14, 2019 at 10:28:41 AM UTC-7, Ryan Kramer wrote: 
> > On Thursday, March 14, 2019 at 12:26:39 AM UTC-5, Alex Harsanyi wrote: 
> > 
> > There are now several projects announced on this list, all of them deal 
> with 
> > data analysis on one way or the other.  Would it be possible to join 
> forces 
> > and merge these projects so that we end up with one library that servers 
> > multiple purposes equally well?  Something where the final product is 
> greater 
> > than the sum of its parts... 
> > 
> > Or perhaps these libraries have aims that are so different from each 
> other 
> > that the only thing they share is a very abstract concept of "table"? 
> > 
> > I think my project "plisqin" is one of those you are thinking of. Matt's 
> "tbl" is also one. I'm also keeping an eye on Ryan's "sql". Are there any 
> more you were thinking of? 
> > 
> > Regarding joining forces/merging these projects, this is a good question 
> that I think warrants discussion. So I'll share my thoughts. 
> > 
> > Obviously I can't speak for all of us, but right not I only see the 
> "very abstract concept of "table"" as potential shared code. (Also, 
> learning about snip% earlier in this thread was awesome. I'd love to use 
> something like that in my project.) 
> > 
> > I think the differences between plisqin and tbl are fairly obvious - 
> plisqin is an alternative to SQL while tbl is an alternative to 
> "Python/NumPy/SciPy, or R/Tidyverse (or, horrors, plain R)" 
> > 
> > Now comparing Ryan's sql to plisqin is a different story. These projects 
> are both alternatives to SQL. But I think there is enough difference 
> between our approaches and scope to warrant separate projects, at least for 
> now. 
> > 1) sql seems to be mostly implemented as macros. plisqin is mostly 
> implemented as procedures. 
> > 2) plisqin has some design decisions that some might consider "too much 
> magic", namely inline joins and "inject-able aggregates" (need better name) 
> as documented here: https://docs.racket-lang.org/plisqin/intro.html. 
> Whereas sql-the-package seems to more closely mirror SQL-the-language - it 
> would be difficult to surprise yourself with the SQL you generate. 
> > 3) I am trying to design #lang plisqin so that people with no Lisp 
> experience can use it. (Whether I will succeed is another matter...) 
> > 
> > I apologize to Ryan C if I have mischaracterized sql. I'd like to have a 
> longer conversation about this, but maybe this list is not the right place. 
> (Also, Ryan, if you think our goals are more similar than I do, I'd be 
> happy to work with you. You're definitely a more experienced Racketeer and 
> it would surely boost my code quality.) 
> > 
> > - Ryan Kramer 
> > 
> > -- 
> > 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 

Re: [racket-users] Re: Pretty display of tabular data?

[jackhfirth]

I think we should all work towards making our existing code in this area 
more discoverable, so we can get a better sense of what libraries for 
working with tables exist in the wild. To those of you who own Racket 
packages that provide any functionality related to data tables: I recommend 
adding the "tabular" tag to your package's description in the package 
catalog. There's no need to remove more-specific tags (like "data-frame") 
from your package, but even if you have a more specific tag please include 
the general "tabular" tag so it's easy to search for your package. So far 
there's only 3 packages 
 tagged with 
"tabular" (and one of those is a package of mine that I just tagged while 
writing this post). I see several packages that are good candidates for the 
tag:

   - data-frame
   - sqlite-table
   - table-panel
   - tabular
   - rml-core (maybe?)
   - sinbad
   - spmatrix (maybe?)
   - spreadsheet-editor
   - csv
   - csv-reading
   - csv-writing
   - simple-csv
   - Most things with the "sql" tag
   
The more packages we have tagged and documented, the easier it will be to 
find real code using tables in the wild. Which is information we'll need if 
we want to understand how a standard `racket/table` API might look.

On Thursday, March 14, 2019 at 10:28:41 AM UTC-7, Ryan Kramer wrote:
>
> On Thursday, March 14, 2019 at 12:26:39 AM UTC-5, Alex Harsanyi wrote:
>
>>
>> There are now several projects announced on this list, all of them deal 
>> with
>> data analysis on one way or the other.  Would it be possible to join 
>> forces
>> and merge these projects so that we end up with one library that servers
>> multiple purposes equally well?  Something where the final product is 
>> greater
>> than the sum of its parts...
>>
>> Or perhaps these libraries have aims that are so different from each other
>> that the only thing they share is a very abstract concept of "table"?
>>
>
> I think my project "plisqin" is one of those you are thinking of. Matt's 
> "tbl" is also one. I'm also keeping an eye on Ryan's "sql". Are there any 
> more you were thinking of?
>
> Regarding joining forces/merging these projects, this is a good question 
> that I think warrants discussion. So I'll share my thoughts.
>
> Obviously I can't speak for all of us, but right not I only see the "very 
> abstract concept of "table"" as potential shared code. (Also, learning 
> about snip% earlier in this thread was awesome. I'd love to use something 
> like that in my project.)
>
> I think the differences between plisqin and tbl are fairly obvious - 
> plisqin is an alternative to SQL while tbl is an alternative to 
> "Python/NumPy/SciPy, or R/Tidyverse (or, horrors, plain R)"
>
> Now comparing Ryan's sql to plisqin is a different story. These projects 
> are both alternatives to SQL. But I think there is enough difference 
> between our approaches and scope to warrant separate projects, at least for 
> now.
> 1) sql seems to be mostly implemented as macros. plisqin is mostly 
> implemented as procedures.
> 2) plisqin has some design decisions that some might consider "too much 
> magic", namely inline joins and "inject-able aggregates" (need better name) 
> as documented here: https://docs.racket-lang.org/plisqin/intro.html. 
> Whereas sql-the-package seems to more closely mirror SQL-the-language - it 
> would be difficult to surprise yourself with the SQL you generate.
> 3) I am trying to design #lang plisqin so that people with no Lisp 
> experience can use it. (Whether I will succeed is another matter...)
>
> I apologize to Ryan C if I have mischaracterized sql. I'd like to have a 
> longer conversation about this, but maybe this list is not the right place. 
> (Also, Ryan, if you think our goals are more similar than I do, I'd be 
> happy to work with you. You're definitely a more experienced Racketeer and 
> it would surely boost my code quality.)
>
> - Ryan Kramer
>

-- 
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: Pretty display of tabular data?

[jackhfirth]

I've wanted this too, and got the sense that working with `snip%` instead 
of `gen:custom-write` was 1) the way to go and 2) very difficult. Are you 
planning on using this in some open source code you have right now in a 
github repo or something similar? I'd like to bookmark it.

On Wednesday, March 13, 2019 at 11:19:07 AM UTC-7, Matt Jadud wrote:
>
> Hi all,
>
> I have a tabular data type that I'd like (I think) to be able to render it 
> either in ASCII or in a prettier way in the Interactions pane. I've 
> explored gen:write and friends, and can get the struct to display the way I 
> want---with ASCII. Essentially easy-peasy.
>
> What I wonder is: am I able to do something prettier? Can I encapsulate 
> some kind of styled rendering as a snip%, or... something... so that I can 
> render the first 5 and last 5 rows of a table with bolding of headers, 
> etc.? 
>
> I don't know where to start, essentially, if I wanted to try and do this. 
> Or, perhaps it is not particularly doable. 
>
> Pointers to examples in codebases are welcome (if such examples exist), 
> and I can work from there. Or, indications that this might be really 
> difficult are also welcome.
>
> Cheers,
> Matt
>
> (Apologies if this somehow comes through twice... I sent it to plt-scheme 
> first...)
>

-- 
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 document modules that reprovide other modules?

[jackhfirth]

If I have two modules `foo` and `foo/extra-thing`, and `foo` requires and 
re-provides all the exports of `foo/extra-thing`, how do I correctly 
document that fact with `defmodule` and `declare-exporting`? The 
documentation for those two scribble forms doesn't include examples, the 
grammars for them are fairly complex, and the only sign I'm using them 
wrong is that the search results for an identifier provided by 
`foo/extra-thing` doesn't include `foo` in the list of modules the 
identifier is exported from. Does someone have a short example of how to 
achieve 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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Struct properties and recursion

[jackhfirth]

Following up on this for anyone interested; I made a small wrapper library (
rebellion/struct-descriptor 
) around 
make-struct-type. You may find it interesting if you've created lots of 
struct types that all had to implement the same methods and properties. The 
library does the following:

   - Defines a struct-descriptor? 
   

 
   data type that combines the values that would be returned by 
   make-struct-type or struct-type-info.
   - Specifies that descriptors may be *initialized* or *uninitialized*, 
   where only initialized descriptors contain a reference to the created 
   struct-type? object.
   - Provides a make-struct-type/descriptor 
   

 
   function that's like make-struct-type, but instead of accepting a list of 
   property implementations it accepts a *property maker function*. This 
   function takes the uninitialized descriptor as an argument and returns a 
   list of property implementations. The make-struct-type/descriptor function 
   returns an initialized descriptor. This makes it easier to abstract over 
   property implementations, as you can make reusable functions that accept 
   uninitialized descriptors as arguments and return property implementations. 
   Oh, and it also has keyword arguments with reasonable defaults so you don't 
   have to look up the docs for all eleven parameters to make-struct-type and 
   write the defaults for the first eight just because the list of immutable 
   positions comes ninth.

This is kind of like the make-struct-type-property API that rocketnia 
mentions:

Instead of defining your `make-list-type-writer` abstraction as a function, 
> you can define it as a structure type property. (I think 
> `prop:auto-custom-write` may be an example of this technique.).This 
> property would make use of multiple features of 
> `make-struct-type-property`: It would first obtain a list of reflective 
> information about the struct type (since that's one of the parameters 
> passed to its guard procedure), and then it would use one of its supers 
> entries to populate `prop:custom-write` based on that information. One part 
> of the reflective information is an accessor procedure, so the generated 
> `prop:custom-write` procedure can call that instead of having to refer to 
> `point-x` and `point-y`.
>
> I find it a little surprising how well this technique corresponds to the 
> needs of a program that's avoiding fixed points. The bundle of reflective 
> information only contains certain information `struct` defines, namely the 
> accessor and mutator procedures. If it contained the structure type 
> descriptor or the constructor, then it would be possible to attempt to 
> access a property value *before* it was done being computed, essentially 
> letting us run into the very kind of use-before-definition error that we'd 
> get if we were using fixed points.
>

I wanted to avoid defining struct types like prop:auto-custom-write (which 
I didn't know about, thanks rocketnia!) that are only used to derive 
implementations of other struct types. That seems to me like it needlessly 
pollutes the API surface of the data types I create, and one function that 
creates all the properties is easier for me to understand than the 
graph-like approach of properties derived from other properties. But it is 
reassuring to know that make-struct-type-property passes information about 
the struct to the guard in a way that's roughly the same as my initialized 
/ uninitialized struct descriptors.

Since then, I've used my struct descriptors to implement two things:

   - make-struct-equal+hash-property 
   
, 
   which implements prop:equal+hash for opaque structs in the same way as the 
   default implementation for #:transparent structs.
   - make-constructor-style-struct-write-property 
   , 
   which implements prop:custom-write using make-constructor-style-printer 
   


Unfortunately I can't implement generic interfaces because there is no 
non-macro interface to that. See 
https://github.com/racket/racket/issues/1647 for some more background on 
that.

-- 
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 

Re: [racket-users] how to use union types

[jackhfirth]

There is, but it's called "wrap your data in a struct". The type checker 
doesn't know that serialization guarantees your schema, and you haven't 
proved that *only* previously-serialized data will be constructed. In order 
to represent this knowledge with types, you can create a struct wrapper in 
a module that exports functions that guarantee the property is checked 
exactly once, when the struct is constructed. This doesn't remove the O(N) 
pass, but it does prevent you from having *multiple* O(N) passes as you 
hand off data between functions. With the struct wrapper, constructing 
instances requires the O(N) check but passing instances between functions 
that accept the struct type is a constant-time struct predicate test.

On Thursday, February 28, 2019 at 2:43:32 PM UTC-8, Brian Craft wrote:
>
> So, when working with large data that is internal to an app, where schema 
> is guaranteed by serialization, there's no way to load that without another 
> O(N) pass to satisfy the type checker?
>
>
> On Thursday, February 28, 2019 at 1:03:48 PM UTC-8, Sam Tobin-Hochstadt 
> wrote:
>>
>> Yes, a cast to a List type checks all the elements of the list. 
>> There's no way to tell if every element of list is a string in less 
>> than O(N) time -- that information just isn't available anywhere. 
>>
>> Sam 
>>
>> On Thu, Feb 28, 2019 at 3:52 PM Brian Craft  wrote: 
>> > 
>> > Really? A cast is also O(N)? 
>> > 
>> > On Thursday, February 28, 2019 at 11:11:01 AM UTC-8, Sam 
>> Tobin-Hochstadt wrote: 
>> >> 
>> >> Any of these solutions need a O(N) traversal of the data. That's 
>> >> because we need to do a full traversal to be sure we got an actual 
>> >> (Listof String) from read-json -- there's no way around it. 
>> >> 
>> >> Sam 
>> >> 
>> >> On Thu, Feb 28, 2019 at 2:04 PM Brian Craft  
>> wrote: 
>> >> > 
>> >> > I would think there'd be a large performance issue, as well, due to 
>> needing an O(N) walk of the data. I'm having type checker issues with 
>> (time), so haven't tested it, but maybe (cast) will get me past those. 
>> >> > 
>> >> > Thanks! 
>> >> > 
>> >> > On Monday, February 25, 2019 at 4:26:52 PM UTC-8, Philip McGrath 
>> wrote: 
>> >> >> 
>> >> >> An alternative to figuring out how to satisfy the type checker is 
>> to use `cast`, e.g.: 
>> >> >> #lang typed/racket 
>> >> >> (require typed/json) 
>> >> >> (string-join 
>> >> >>  (cast 
>> >> >>   (string->jsexpr 
>> >> >>"[\"The\",\"quick\",\"brown\",\"fox\",\"...\"]") 
>> >> >>   (Listof String))) 
>> >> >> 
>> >> >> Obviously this has pros and cons, the main pro being that it runs. 
>> The biggest con, in my view, is that you effectively are dropping into 
>> untyped world. If you figure out how to satisfy the type checker, you get 
>> assurance that your code is well-typed, which is presumably what you want 
>> if your using Typed Racket in the first place. Using `cast` means that you 
>> are responsible for making sure that expression has the type you say it 
>> does, without help from Typed Racket, or you will get a runtime error. For 
>> example, I often forget that `read-json` might return `eof` rather than a 
>> `JSExpr`. Also, `cast` uses the contract machinery, which can carry 
>> performance costs. 
>> >> >> 
>> >> >> But the fact that it runs is not a small benefit, especially if it 
>> lets you fill in other parts of your program and come back to remove the 
>> `cast` later. It also lets you take advantage of Typed Racket to generate 
>> any complicated runtime checks. 
>> >> >> 
>> >> >> -Philip 
>> >> >> 
>> >> >> 
>> >> >> On Mon, Feb 25, 2019 at 6:49 PM  wrote: 
>> >> >>> 
>> >> >>> A JSExpr is one of a couple of things: 
>> >> >>> 
>> >> >>> - A list 
>> >> >>> - A hash with symbol keys 
>> >> >>> - A number 
>> >> >>> - A string 
>> >> >>> - A boolean 
>> >> >>> - Null 
>> >> >>> 
>> >> >>> The (andmap string?) approach implicitly assumes you're giving it 
>> a list. But it might be something else instead, so you want this: (and 
>> (list? js) (andmap string? js)) 
>> >> >>> 
>> >> >>> On Monday, February 25, 2019 at 3:44:38 PM UTC-8, Brian Craft 
>> wrote: 
>> >>  
>> >>  So, that also gives me a type error: 
>> >>  
>> >>   Type Checker: Polymorphic function `andmap' could not be applied 
>> to arguments: 
>> >>  Domains: (-> a b ... b c) (Listof a) (Listof b) ... b 
>> >>   (-> a c : d) (Listof a) 
>> >>  Arguments: (-> Any Boolean : String) (U EOF JSExpr) 
>> >>  
>> >>    in: (andmap string? s) 
>> >>  
>> >>  
>> >>  On Monday, February 25, 2019 at 3:22:12 PM UTC-8, Sam 
>> Tobin-Hochstadt wrote: 
>> >> > 
>> >> > I think (andmap string? ...) is probably the easiest way to 
>> check that. 
>> >> > 
>> >> > Sam 
>> >> > 
>> >> > On Mon, Feb 25, 2019, 6:20 PM Brian Craft  
>> wrote: 
>> >> >> 
>> >> >> In typed racket, parsing a string list gives me a JSExpr, which 
>> is a union. I need to pass it to functions that operate on 

Re: [racket-users] how to use union types

[jackhfirth]

A JSExpr is one of a couple of things:

- A list
- A hash with symbol keys
- A number
- A string
- A boolean
- Null

The (andmap string?) approach implicitly assumes you're giving it a list. 
But it might be something else instead, so you want this: (and (list? js) 
(andmap string? js))

On Monday, February 25, 2019 at 3:44:38 PM UTC-8, Brian Craft wrote:
>
> So, that also gives me a type error:
>
>  Type Checker: Polymorphic function `andmap' could not be applied to 
> arguments:
> Domains: (-> a b ... b c) (Listof a) (Listof b) ... b
>  (-> a c : d) (Listof a)
> Arguments: (-> Any Boolean : String) (U EOF JSExpr)
>
>   in: (andmap string? s)
>
>
> On Monday, February 25, 2019 at 3:22:12 PM UTC-8, Sam Tobin-Hochstadt 
> wrote:
>>
>> I think (andmap string? ...) is probably the easiest way to check that. 
>>
>> Sam
>>
>> On Mon, Feb 25, 2019, 6:20 PM Brian Craft  wrote:
>>
>>> In typed racket, parsing a string list gives me a JSExpr, which is a 
>>> union. I need to pass it to functions that operate on string lists, but 
>>> can't figure out how to please the type checker. Maybe with occurrence 
>>> typing? But I don't know how to assert "this is a list of strings".
>>>
>>> -- 
>>> 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] Use cases for tables and records

[jackhfirth]

Hi folks! I'm looking for use cases for a few small data structure 
libraries I'm working on:

- Records , which are 
dictionaries mapping keywords to values. Keys must be keywords, which 
allows for more efficient behavior in various cases and sometimes 
cooperates nicely with keyword arguments. Example:

> (define rec (record #:person "Joe Schmoe" #:age 30 #:favorite-color 
'blue))
> (record-ref rec '#:age)
30

- Tables , which are 
like a list of records that all have the same keywords. Tables are similar 
to dataframes and are intended to make it easy to process spreadsheet-like 
data such as CSV files. Example:

(table (columns #:name #:population #:capital-city)
 (row "Argentina" 4380 "Buenos Aires")
 (row "Greece" 1080 "Athens")
 (row "Nigeria" 19860 "Abuja")
 (row "Japan" 12640 "Tokyo"))

The libraries are really just bare-bones skeletons at the moment and are 
missing a lot of core features. Still, if they seem like things that you 
would use, please let me know how! Pointers to code "in the wild" where you 
think these libraries would help are especially useful. Pointers to similar 
libraries (like the data-frame 
 package) and 
discussions about their advantages / disadvantages are also helpful.

-- 
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] Running raco setup from within DrRacket?

[jackhfirth]

Using setup/setup works partially, but it doesn't seem to support package 
dependency checking (and the #:pkgs keyword argument isn't documented). I 
can't seem to find any programmatic alternative to the --check-pkg-deps and 
--unused-pkg-deps flags.

On Friday, February 15, 2019 at 8:35:17 PM UTC-8, Matthias Felleisen wrote:
>
> See 
> https://docs.racket-lang.org/raco/setup-plt-plt.html?q=setup#%28def._%28%28lib._setup%2Fsetup..rkt%29._setup%29%29
>  
>
> (require setup/setup) 
>
> I think that’s what you want — 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.

[racket-users] Running raco setup from within DrRacket?

[jackhfirth]

Whenever I change code in my package I switch over to the terminal and 
recompile it with `raco setup`. This is slightly tedious and I’d like to be 
able to do this from within DrRacket. But I’m not sure how to translate the 
command `raco setup --doc-index --check-pkg-deps --tidy --unused-pkg-deps 
--pkgs ` into a runnable racket module. I tried the following:

   1. Using `system*` didn’t work because it doesn’t search `$PATH` and so 
   it can’t find `raco`.
   2. Using `(find-executable-path "raco")` didn’t work either, it just 
   returned false.
   3. Trying to invoke the setup command using `dynamic-require` and 
   `raco/all-tools` *started* `raco setup` successfully, but then failed 
   because for some reason the setup command was trying to read and tidy up 
   stale DrRacket-specific zos (the stuff in `compiled/drracket` 
   subdirectories).

What should I do here?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] struct-info

[jackhfirth]

>
> This is nice for defining abstract types, but it can be pretty 
>> inconvenient for defining plain old aggregated data types that just have a 
>> bundle of fields. When defining those types as structs, consider using the 
>> #:transparent option. This means "use no inspector at all" (roughly) and 
>> lets `struct-info` Just Work (TM) without any inspector wrangling. The 
>> downside is that other modules may be able to break your type's invariants 
>> and possibly circumvent your contracts. 
>
>
> That's what I expected, but it doesn't seem to work: 
>
> > (struct person (name age) #:transparent) 
> > (struct-info person) 
> #f 
> #t 
>
> What am I missing?
>

I was stumped on this for a while, but then realized the problem:

> (struct-info person)
#f
#t
> (struct-info (person "Alyssa P. Hacker" 42))
#
#f

-- 
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] struct-info

[jackhfirth]

>
> Thank you for the explanation.  Can I ask why the heck it works this 
> way?  This seems to be explicitly designed for maximal surprise and 
> minimal usefulness. 
>

It works that way so that, by default, modules can't inspect, modify, or 
otherwise muck around with structs defined by other modules. Opaque structs 
(that is, structs that aren't transparent and aren't prefab) aren't really 
meant to be used like "plain old data objects" with fields and accessors, 
they're more like building blocks for abstract data types. A module that 
defines an opaque struct type is expected to be responsible for exporting 
to other modules all the functions that are necessary for using that type. 
Anything not explicitly exported by the module is not allowed, even through 
reflective operations like struct-info. The exception to this rule is when 
some entity *above* the modules is controlling them all, such as a 
debugger, an IDE, or a server running client-supplied code. In these cases, 
the controlling code has the option to make a child inspector and run all 
the modules under that child inspector, giving the controlling code access 
to all struct types through the parent inspector. This kind of setup can be 
nested arbitrarily deep.

This is nice for defining abstract types, but it can be pretty inconvenient 
for defining plain old aggregated data types that just have a bundle of 
fields. When defining those types as structs, consider using the 
#:transparent option. This means "use no inspector at all" (roughly) and 
lets `struct-info` Just Work (TM) without any inspector wrangling. The 
downside is that other modules may be able to break your type's invariants 
and possibly circumvent your contracts.

-- 
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] Collections and data structures wishlist?

[jackhfirth]

On Friday, January 18, 2019 at 11:50:48 PM UTC-8, Matthias Felleisen wrote:
>
>
> On Jan 18, 2019, at 10:22 PM, jackh...@gmail.com  wrote:
>
>
> - A separation between using lists as homogeneous collections and using 
> lists as fixed-size tuples. So there'd be a separate `tuple?` data type 
> that's structurally equivalent to a list but meant to be used differently. 
> For example, `(list/c number?)` would mean a list of many numbers, but 
> `(tuple/c number?)` would mean a tuple of size 1 containing a number.
>
>
>
> "It is better to have 100 functions operate on one data structure than 10 
> functions on 10 data structures.” 
> http://www.cs.yale.edu/homes/perlis-alan/quotes.html
> "It is better to have 100 transducers operate on one data structure 
> interface than 10 functions on 10 data structures.” Rich Hickey, History of 
> Clojure 
>

100 functions on one data structure is how you end up with unreadable 
function names like list* and cadadr.

-- 
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] Collections and data structures wishlist?

[jackhfirth]

When it comes to collections and data structures, what would you all like 
to see in Racket2? New APIs? Changes to existing APIs? Whole new paradigms? 
Something else?

I've got my own wishlist and maybe someday I'll implement a few things on 
it as packages, but I'm curious what everyone else thinks. For some 
examples, here's a few things on my list:

- Distinct data types for pairs and lists, and more intuitive names for the 
pair APIs (so `pair?` and `list?` would be mutually exclusive predicates 
and you'd make and access pairs with `(pair 1 2)`, `(pair-first p)`, and 
`(pair-second p)`.

- A separation between using lists as homogeneous collections and using 
lists as fixed-size tuples. So there'd be a separate `tuple?` data type 
that's structurally equivalent to a list but meant to be used differently. 
For example, `(list/c number?)` would mean a list of many numbers, but 
`(tuple/c number?)` would mean a tuple of size 1 containing a number.

- Something better and simpler than structs. Throw out mutable fields, 
subtyping, struct type properties, etc. Just the basics: a tuple-like type 
with named fields and a constructor that can enforce invariants on all 
instances.

- Lots more stuff.

-- 
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.