Re: [racket-users] Standardizing the threading macro and organizing packages

In addition to agreeing with you and Sam here Alexis, I would like to point out another thing that has worked well for Racket in design situations such as these: benevolent despotism. That is, the person in charge of the design is expected to fully and deeply understand what they have designed

Re: [racket-users] planet questions

Also, I would suggest that you use the package system, not planet for new packages. Planet is a system we plan to continue to maintain, but the package system is the future (and the present, really). You can read more about how to get started here: http://docs.racket-lang.org/pkg/index.html

Re: off topic, Re: [racket-users] Defining a symbol breaks symbols?

Yes, sorry, I've been traveling and didn't have time to respond. I was originally tempted to say "statically typed" and then realized that wasn't exactly right, because it was not static types that would forbid such a construction, so I said "static languages" suggesting languages where things

Re: [racket-users] planet questions

At Wed, 7 Oct 2015 17:35:44 -0700 (PDT), Anurag Mendhekar wrote: > Having just submitted my first contribution to Planet [Note: We use the name "Planet" for an older package system. I see that you uploaded a package in the new system; assuming that you didn't also upload to the old system,

Re: [racket-users] fail on http server response not actually a failure?

I just put in a catch for this. If you can let me know if it squashes it would be great! Jay On Thu, Oct 8, 2015 at 12:19 AM, John B. Clements wrote: > >> On Oct 6, 2015, at 6:58 AM, Jay McCarthy wrote: >> >> I'm not sure if this answers the

Re: [racket-users] Separate compilation vs macros in signatures and compiler stacktraces (crashes?)

(Old thread ...) I only want to add an example of identifier capture. Here the identifier _it_ is not bound at the macro compiling time, but is bound at the final code. Note: Capture is discouraged in Racket. I think that 99% of the times, the unbound identifiers are just typos, like displyaln.

[racket-users] Re: Standardizing the threading macro and organizing packages

> Duplication is an uncomfortably common problem in Lispy circles, but > fragmentation is never a good thing To be fair, there are plenty of good reasons why duplication / fragmentation would exist, many of them ultimately beneficial to the underlying system. Fragmentation is not per se bad.

Re: [racket-users] planet questions

On Thu, Oct 8, 2015 at 9:18 AM, Matthew Flatt wrote: > At Wed, 7 Oct 2015 17:35:44 -0700 (PDT), Anurag Mendhekar wrote: >> Having just submitted my first contribution to Planet > > [Note: We use the name "Planet" for an older package system. I see that > you uploaded a package

Re: [racket-users] Standardizing the threading macro and organizing packages

On Thu, Oct 8, 2015 at 10:56 AM, Greg Hendershott wrote: > - If you do want a Clojure style threading _macro_, rackjure's is the > best implementation now AFAIK. I say that with no ego because that's > mostly thanks to help from people like Sam and Christoffer Sawicki.

Re: [racket-users] fail on http server response not actually a failure?

> On Oct 8, 2015, at 7:13 AM, Jay McCarthy wrote: > > I just put in a catch for this. If you can let me know if it squashes > it would be great! I’ll do that. Well, maybe. The machine that’s running this is as close to a “production” server as it gets, for me,

Re: off topic, Re: [racket-users] Defining a symbol breaks symbols?

> On Oct 8, 2015, at 9:00 AM, Lyle Kopnicky wrote: > > Yes, sorry, I've been traveling and didn't have time to respond. I was > originally tempted to say "statically typed" and then realized that wasn't > exactly right, because it was not static types that would forbid

Re: [racket-users] planet questions

Thanks for the detailed response, and apologies for the confusion regarding the nomenclature. I did use the new package system, but in my head it is still planet :-) Anything I can do about the failure on libWN? Best, A. On Thu, Oct 8, 2015 at 7:18 AM, Matthew Flatt wrote:

Re: [racket-users] Standardizing the threading macro and organizing packages

Why Rackjure - rackjure is something I started casually, didn't expect it would ever get 100 stars. On the other hand, I suspect nearly all of those stars are "huh, interesting". Not "I actually use this". :) - I have no emotional investment in it. Just feel an obligation to support it for

[racket-users] built with racket web-badge?

Cal Poly has a team competing in the Solar Decathlon this year, a nationwide competition to build a spiffy solar house and bring it to Irvine for a week: http://www.solardecathlon.gov/ As part of this, we built a small server running in Racket, natch. Here’s a web page that’s a front-end for

[racket-users] missing flarray?

Is there a type-predicate for flarray? Berthold -- --- Berthold Bäuml -- Head of Autonomous Learning Robots Lab DLR, Robotics and Mechatronics Center (RMC) Münchner Str. 20, D-82234 Wessling Phone +49 8153 282489

Re: [racket-users] Standardizing the threading macro and organizing packages

I decided to release my threading implementation as the “threading” package. The documentation is here: http://pkg-build.racket-lang.org/doc/threading/index.html I’m okay with this because I wanted to pull them out of my utils package, anyway, and they’re nice to have, even if we come up with a

Re: [racket-users] Re: Standardizing the threading macro and organizing packages

On Wed, 07 Oct 2015 23:02:23 -0500, Jack Firth wrote: > If this isn't going to be added to the core (and I don't think it > should), then there would need to be some work done on exposure and > making sure everyone who wants this functionality knows "look here > first and only roll your own if

Re: [racket-users] Re: Embedding in standard C/C++ leads to segfaults

The root of the problem seems to be that `-std=c89` disables C preprocessor definitions like `linux`, so definition like `__linux__` must be detected instead. Specifically, on x86-64 Linux, a cascade of preprocessor-based configuration choices cause `mz_long_double` to be either `long double` or

Re: [racket-users] Standardizing the threading macro and organizing packages

You don't think (define-simple-macro (-> var:id expr:expr ...+) (let* ([var expr] ...) var)) Is better? It's more powerful, because it allows placeholders to be arbitrarily nested within the expressions. Also, it allows the user to supply their own identifier to use as a placeholder instead

Re: [racket-users] planet questions

The details below avoid needing "libWN" on install. If you want to enable tests of other things that need to use "libWN", see "Working with Native Libraries" here: http://pkg-build.racket-lang.org/about.html At Thu, 8 Oct 2015 08:54:14 -0700, Anurag Mendhekar wrote: > Thanks for the detailed

Re: [racket-users] built with racket web-badge?

Oh yeah? Well _I_ promote him to Grand Chief Design Office (GCDO) though the powers bestowed on my by our CEO (little does he care). Robby On Thu, Oct 8, 2015 at 1:04 PM, Matthias Felleisen wrote: > > On Oct 8, 2015, at 12:06 PM, "'John B. Clements' via Racket Users" >

Re: [racket-users] built with racket web-badge?

On Oct 8, 2015, at 12:06 PM, "'John B. Clements' via Racket Users" wrote: > I am not volunteering to tackle this: well, maybe if I get promoted. I herewith promote you to Chief Design Officer (CDO) through the powers bestowed on me by our CEO (little does he

Re: [racket-users] Standardizing the threading macro and organizing packages

> On Oct 8, 2015, at 2:27 PM, Alexis King wrote: > > >> On Oct 8, 2015, at 11:08 AM, Alex Knauth wrote: >> >> You don't think >> (define-simple-macro (-> var:id expr:expr ...+) >> (let* ([var expr] ...) var)) >> >> Is better? > > No, actually

Re: [racket-users] Standardizing the threading macro and organizing packages

> On Oct 8, 2015, at 1:34 PM, Jay McCarthy wrote: > > FWIW, I find my threading macro to be very powerful, pretty clear when > used complicatingly, and at about power-level 9,000: > > https://github.com/jeapostrophe/exp/blob/master/threading-arrow.rkt I have to agree

Re: [racket-users] Standardizing the threading macro and organizing packages

FWIW, I find my threading macro to be very powerful, pretty clear when used complicatingly, and at about power-level 9,000: https://github.com/jeapostrophe/exp/blob/master/threading-arrow.rkt My opinion is to include something like this in remix along with some nice syntax for cut (what ignorant

Re: [racket-users] Standardizing the threading macro and organizing packages

> On Oct 8, 2015, at 4:48 PM, Jay McCarthy wrote: > A key thing that Remix has is buttery C-like syntax for infix dots. So > you can write r.ul.x and it might be the same as (posn-x (rectangle-ul > r)) if `r` were bound to a "dot transformer" that looked for .ul and > so

Re: [racket-users] Standardizing the threading macro and organizing packages

On Thu, Oct 8, 2015 at 6:23 PM, Alexis King wrote: >> On Oct 8, 2015, at 1:34 PM, Jay McCarthy wrote: >> >> FWIW, I find my threading macro to be very powerful, pretty clear when >> used complicatingly, and at about power-level 9,000: >> >>

Re: [racket-users] built with racket web-badge?

On Oct 8, 2015, at 2:48 PM, Ian Barland wrote:My question is this: has anyone created a “built with Racket” badge that I could put at the bottom of this page? The closest things I have are the Racket badge at the top of racket-lang.org, and the ancient “powered by PLT” and

Re: [racket-users] built with racket web-badge?

On Thu, Oct 8, 2015 at 6:05 PM, 'John Clements' via Racket Users < racket-users@googlegroups.com> wrote: > > Curiously, I think we’re still incorporated as PLT Scheme, Inc. > No, the name is officially "PLT Design Inc." (no comma). Robby -- You received this message because you are

Re: [racket-users] built with racket web-badge?

> On Oct 8, 2015, at 11:12 AM, Robby Findler > wrote: > > Oh yeah? Well _I_ promote him to Grand Chief Design Office (GCDO) > though the powers bestowed on my by our CEO (little does he care). > I’m up for full at the end of this year, and I admit that I was

Re: [racket-users] Standardizing the threading macro and organizing packages

I agree about using the function form for flexibility. (Alliteration!) The macro form should be optimized for simple cases, because macros by nature are less flexible. If you have a complex case, write actual functions. You'll spend less time wrangling the syntax system that way. On Thu, Oct 8,

Re: [racket-users] Standardizing the threading macro and organizing packages

On Thu, Oct 8, 2015 at 6:48 PM, Jay McCarthy wrote: > >>> My opinion is to include something like this in remix along with some >>> nice syntax for cut (what ignorant people call "function literals".) >> >> I admit I can’t really disagree with this point. I’m mostly just

Re: [racket-users] Standardizing the threading macro and organizing packages

> On Oct 8, 2015, at 4:51 PM, Jack Firth wrote: > > Looking at that one, I'm against back-referencing N clauses with (<> n). I > find it very difficult to read, and it strikes me as particularly fragile if > you're inserting or removing steps into the flow as you edit

Re: [racket-users] Standardizing the threading macro and organizing packages

The more I think about it, the more I realize I really dislike specifying the position of arguments in these anonymous function syntaxes. For instance I would prefer this: (λ (x y) (/ y x)) To this: λ.(/ $.1 $.0) In the common case, you won't need to flip any argument orders around. In that

Re: [racket-users] Standardizing the threading macro and organizing packages

> My macro and Jack Firth's function both allow that. Sounds like the solution is to go with a function instead of a macro then. If you want that flexibility, I don’t think there’s any reason to stick with a macro, anyway. The point-free package is very nice. Alexis -- You received this

Re: [racket-users] Standardizing the threading macro and organizing packages

> Quick! Should (~>> (~>> a b) (~>> c d)) be equal to (~>> (b a) (~>> c d)) ? Well, I wouldn't want to write or read code like that. If I'm using a threading macro, at all, it's to reduce nesting, and emphasize the "flat", "pipeline" quality of some computations. As a result I'm not eager to

Re: [racket-users] built with racket web-badge?

Here are some alternative badges I threw together earlier this afternoon: http://imgur.com/a/WaKs5 No Racket code, though, because they were made in photoshop. -- Cam On Thursday, October 8, 2015 at 6:22:56 PM UTC-5, Robby Findler wrote: > On Thu, Oct 8, 2015 at 6:05 PM, 'John Clements' via

[racket-users] Documentation for array-axis-permute

I couldn't easily see another place to make this comment. I'm working on SRFI-122, YAAL (Yet Another Array Library), so I'm studying other array libraries and am trying to understand array-axis-permute in the math/array Racket library:

Re: [racket-users] Standardizing the threading macro and organizing packages

> On Oct 8, 2015, at 11:08 AM, Alex Knauth wrote: > > You don't think > (define-simple-macro (-> var:id expr:expr ...+) > (let* ([var expr] ...) var)) > > Is better? No, actually I, I don’t. Threading macros are a convenience, just like anonymous functions. I’d rather

Re: [racket-users] Standardizing the threading macro and organizing packages

> On Oct 8, 2015, at 2:27 PM, Alexis King wrote: > > The original threading macro is a simple macro that unwinds nested function > application. Implementation aside, I find that the most intuitive way to > visualize it—introducing binding makes that more complicated,