Re: [racket-users] Re: Naming conventions for private functions

2017-10-13 Thread David Storrs 
Cool.  Thank you, Robby and Matthias.



On Fri, Oct 13, 2017 at 9:50 PM, Robby Findler
 wrote:
> If you want to know what the current racket does (not what the
> chez-based one does), then you can "raco make x.rkt" and then "raco
> decompile x.rkt" to see what is going on.
>
> In the cod quoted below, no closures are allocated because all of the
> functions bar, baz, and jaz are eliminated before runtime.
>
> The current compiler doesn't try to do anything with set!, so if you
> changed the program to this one:
>
> #lang racket
>
> (define (foo.1 x)
>   (define (bar) x)
>   (set! bar bar)
>   (bar))
>
> (define (foo.2 x)
>   (define (baz) 8)
>   (define (jaz) x)
>   (set! baz baz)
>   (set! jaz jaz)
>   (println (jaz))
>   (baz))
>
>
> you will see some lambda expressions survive.
>
> Of course, this may not be a bad thing, depending on what the actual
> application itself is doing. And it may be the case that some of those
> with empty closures aren't allocated, depending on various factors.
>
> Robby
>
>
> On Fri, Oct 13, 2017 at 8:19 PM, David Storrs  wrote:
>> On Fri, Oct 13, 2017 at 2:57 PM, Matthias Felleisen
>>  wrote:
>>>
 On Oct 13, 2017, at 2:55 PM, David Storrs  wrote:

 On Fri, Oct 13, 2017 at 2:50 PM, David Storrs  
 wrote:
> Coming from a Perl background, I've long had a convention of naming
> private functions with a leading underscore, e.g. _do-the-thing.  Is
> there a standard Racket convention for this and, if so, what is it?

 Addendum:  I know that I can define functions inside the function for
 which they are the helper, but my understanding is that if I do that
 then the helper function is recompiled every time the parent function
 is executed.

 (define (flurble args)
   (define (helper-func) ...do stuff...)
   (helper-func ...))

 (for ((i 1))
  (flurble i)) ; helper-func will be built 10,000 times, right?
>>>
>>>
>>> No it isn’t recompiled. But the run-time may allocate a closure a second 
>>> time.
>>> Lambda lifting and similar techniques should avoid this but not necessarily 
>>> in
>>> the current compiler.
>>
>>
>> (define (foo x)
>> (for ((i 1))
>> (define (bar) x)
>> (bar)))
>>
>> So bar will be allocated 10,000 times in the above?  How about baz and
>> jaz in the below?
>>
>>
>> (define (foo x)
>>   (define (baz) 8)
>>   (define (jaz) x)
>>   (println (jaz))
>>   (baz))
>>
>> (for ((i 1))
>>   (foo 7))
>>
>> --
>> 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.

-- 
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] Multiple namespaces in Racket

2017-10-13 Thread Geoffrey Knauth 
On Friday, October 13, 2017 at 1:06:15 PM UTC-4, Alexis King wrote:
>
> At this point, though it is indisputably evil, it seems more feasible 
> to use some name mangling scheme than to expand to a submodule. That 
> would be, of course, deeply unsatisfying, so I would very much like to 
> have a better solution. 
>

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

-- 
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: Naming conventions for private functions

2017-10-13 Thread Robby Findler 
If you want to know what the current racket does (not what the
chez-based one does), then you can "raco make x.rkt" and then "raco
decompile x.rkt" to see what is going on.

In the cod quoted below, no closures are allocated because all of the
functions bar, baz, and jaz are eliminated before runtime.

The current compiler doesn't try to do anything with set!, so if you
changed the program to this one:

#lang racket

(define (foo.1 x)
  (define (bar) x)
  (set! bar bar)
  (bar))

(define (foo.2 x)
  (define (baz) 8)
  (define (jaz) x)
  (set! baz baz)
  (set! jaz jaz)
  (println (jaz))
  (baz))


you will see some lambda expressions survive.

Of course, this may not be a bad thing, depending on what the actual
application itself is doing. And it may be the case that some of those
with empty closures aren't allocated, depending on various factors.

Robby


On Fri, Oct 13, 2017 at 8:19 PM, David Storrs  wrote:
> On Fri, Oct 13, 2017 at 2:57 PM, Matthias Felleisen
>  wrote:
>>
>>> On Oct 13, 2017, at 2:55 PM, David Storrs  wrote:
>>>
>>> On Fri, Oct 13, 2017 at 2:50 PM, David Storrs  
>>> wrote:
 Coming from a Perl background, I've long had a convention of naming
 private functions with a leading underscore, e.g. _do-the-thing.  Is
 there a standard Racket convention for this and, if so, what is it?
>>>
>>> Addendum:  I know that I can define functions inside the function for
>>> which they are the helper, but my understanding is that if I do that
>>> then the helper function is recompiled every time the parent function
>>> is executed.
>>>
>>> (define (flurble args)
>>>   (define (helper-func) ...do stuff...)
>>>   (helper-func ...))
>>>
>>> (for ((i 1))
>>>  (flurble i)) ; helper-func will be built 10,000 times, right?
>>
>>
>> No it isn’t recompiled. But the run-time may allocate a closure a second 
>> time.
>> Lambda lifting and similar techniques should avoid this but not necessarily 
>> in
>> the current compiler.
>
>
> (define (foo x)
> (for ((i 1))
> (define (bar) x)
> (bar)))
>
> So bar will be allocated 10,000 times in the above?  How about baz and
> jaz in the below?
>
>
> (define (foo x)
>   (define (baz) 8)
>   (define (jaz) x)
>   (println (jaz))
>   (baz))
>
> (for ((i 1))
>   (foo 7))
>
> --
> 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.

-- 
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: Naming conventions for private functions

2017-10-13 Thread Matthias Felleisen 

> On Oct 13, 2017, at 9:19 PM, David Storrs  wrote:
> 
> On Fri, Oct 13, 2017 at 2:57 PM, Matthias Felleisen
>  wrote:
>> 
>>> On Oct 13, 2017, at 2:55 PM, David Storrs  wrote:
>>> 
>>> On Fri, Oct 13, 2017 at 2:50 PM, David Storrs  
>>> wrote:
 Coming from a Perl background, I've long had a convention of naming
 private functions with a leading underscore, e.g. _do-the-thing.  Is
 there a standard Racket convention for this and, if so, what is it?
>>> 
>>> Addendum:  I know that I can define functions inside the function for
>>> which they are the helper, but my understanding is that if I do that
>>> then the helper function is recompiled every time the parent function
>>> is executed.
>>> 
>>> (define (flurble args)
>>>  (define (helper-func) ...do stuff...)
>>>  (helper-func ...))
>>> 
>>> (for ((i 1))
>>> (flurble i)) ; helper-func will be built 10,000 times, right?
>> 
>> 
>> No it isn’t recompiled. But the run-time may allocate a closure a second 
>> time.
>> Lambda lifting and similar techniques should avoid this but not necessarily 
>> in
>> the current compiler.
> 
> 
> (define (foo x)
>(for ((i 1))
>(define (bar) x)
>(bar)))
> 
> So bar will be allocated 10,000 times in the above?  How about baz and
> jaz in the below?


This kind of situation is covered by ‘lightweight closure’ conversion, 
which we added in the late 90s and should still be there. Note how 
all instances of bar are identical. No need to re-allocate. 



> 
> 
> (define (foo x)
>  (define (baz) 8)
>  (define (jaz) x)
>  (println (jaz))
>  (baz))
> 
> (for ((i 1))
>  (foo 7))

Again, baz is covered trivially. 

Only a whole-program analysis can confirm that foo is applied to only 7 
and therefor jaz is the same closure on every call to foo. 

;; - - - 

Note that programs can use eq? to compare closures. I am ignoring this aspect. 




-- 
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: Naming conventions for private functions

2017-10-13 Thread David Storrs 
On Fri, Oct 13, 2017 at 2:57 PM, Matthias Felleisen
 wrote:
>
>> On Oct 13, 2017, at 2:55 PM, David Storrs  wrote:
>>
>> On Fri, Oct 13, 2017 at 2:50 PM, David Storrs  wrote:
>>> Coming from a Perl background, I've long had a convention of naming
>>> private functions with a leading underscore, e.g. _do-the-thing.  Is
>>> there a standard Racket convention for this and, if so, what is it?
>>
>> Addendum:  I know that I can define functions inside the function for
>> which they are the helper, but my understanding is that if I do that
>> then the helper function is recompiled every time the parent function
>> is executed.
>>
>> (define (flurble args)
>>   (define (helper-func) ...do stuff...)
>>   (helper-func ...))
>>
>> (for ((i 1))
>>  (flurble i)) ; helper-func will be built 10,000 times, right?
>
>
> No it isn’t recompiled. But the run-time may allocate a closure a second time.
> Lambda lifting and similar techniques should avoid this but not necessarily in
> the current compiler.


(define (foo x)
(for ((i 1))
(define (bar) x)
(bar)))

So bar will be allocated 10,000 times in the above?  How about baz and
jaz in the below?


(define (foo x)
  (define (baz) 8)
  (define (jaz) x)
  (println (jaz))
  (baz))

(for ((i 1))
  (foo 7))

-- 
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: Naming conventions for private functions

2017-10-13 Thread David Storrs 
On Fri, Oct 13, 2017 at 2:59 PM, Robby Findler
 wrote:
> Also: if you just don't `provide` a function from a module, then it
> cannot be used outside. No naming conventions necessary.
>

Sure, but the underscore helps me know at a glance what I'm looking
at, whether it's safe to make a breaking change to a function, etc.

> Robby
>
> On Fri, Oct 13, 2017 at 1:57 PM, Matthias Felleisen
>  wrote:
>>
>>> On Oct 13, 2017, at 2:55 PM, David Storrs  wrote:
>>>
>>> On Fri, Oct 13, 2017 at 2:50 PM, David Storrs  
>>> wrote:
 Coming from a Perl background, I've long had a convention of naming
 private functions with a leading underscore, e.g. _do-the-thing.  Is
 there a standard Racket convention for this and, if so, what is it?
>>>
>>> Addendum:  I know that I can define functions inside the function for
>>> which they are the helper, but my understanding is that if I do that
>>> then the helper function is recompiled every time the parent function
>>> is executed.
>>>
>>> (define (flurble args)
>>>   (define (helper-func) ...do stuff...)
>>>   (helper-func ...))
>>>
>>> (for ((i 1))
>>>  (flurble i)) ; helper-func will be built 10,000 times, right?
>>
>>
>> No it isn’t recompiled. But the run-time may allocate a closure a second 
>> time.
>> Lambda lifting and similar techniques should avoid this but not necessarily 
>> in
>> the current compiler.
>>
>> --
>> 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.

-- 
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] Naming conventions for private functions

2017-10-13 Thread Neil Van Dyke 

I don't think there's a convention, and I've not yet found an ideal one.

Around 2000, with portable RnRS-ish Scheme absent a module system, I 
started using a convention that I think I took from Olin Shivers, which 
is to prefix non-public toplevel identifiers with `%`.  (At one point, I 
even had a script to use this convention to take these portable files 
and generate dialect-specific ones, such as PLT Scheme ones with 
generated `provide` forms at the end.)


Then, considering that sometimes these identifiers show up in error 
messages and debugging tracebacks, I started prefixing with `%`, 
followed by the the library name, followed by `:`.  That's good for 
debugging, but makes the non-public identifiers harder to read in the 
code in some ways, and unpleasant to type.


I have a related convention, in which a `provide` form immediately 
precedes any definition form that defines exported things.  I should 
start using a `define/provide` regularly, to eliminate most of the 
clutter this causes.  (I found that the separate big `provide` lists 
elsewhere just waste a lot of time, and introduce errors.  There are 
other ways to get a summary sense of what's defined in the module.)


Better tool and debugging support could help (e.g., not having to embed 
package name in the identifier because sufficient location is always 
going to be available from error messages/tracebacks/debuggers, maybe 
syntax coloring in an editor to distinguish exported vs. non-exported 
among other properties).


--
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: Naming conventions for private functions

2017-10-13 Thread Eric Eide 
Robby Findler  writes:

> Also: if you just don't `provide` a function from a module, then it
> cannot be used outside. No naming conventions necessary.

But the no-naming convention is necessary.
:-).

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

Re: [racket-users] can't (require table-panel) today

2017-10-13 Thread Geoff Knauth 
Doh!  Ok, it’s me.  I don’t know why I assumed table-panel was included out of 
the box.

Thank you Dmitry!

Geoff Knauth (mobile)Ты

> On Oct 13, 2017, at 14:59, Dmitry Pavlov  wrote:
> 
> 
> 
>> #lang racket/gui
>> (require table-panel)
>> 
>> leads to:
>> 
>> standard-module-name-resolver: collection not found
> Have you tried raco pkg install table-panel?
> 
> Best regards,
> 
> Dmitry
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Racket Users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/racket-users/I7mlqYEjMWA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> racket-users+unsubscr...@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.

Re: [racket-users] Intro and projects inquiry

2017-10-13 Thread Eric Griffis 
On Thu, Oct 12, 2017 at 2:27 PM Andrew Gwozdziewycz 
wrote:

> I love seeing all of these project ideas, but I really don't think
> Racket needs a "killer app." I think what it needs is the people
> passionate about it building tools in it, and *using* those tools in
> the work place, and sharing the experiences of using those tools more
> vocally.
>

This line of reasoning also works in reverse. When Racket becomes more
popular, people will talk about it more. There's a network effect to
consider.


> We need people building tools and blogging about why using Racket made
> the job easier. Why would it be harder to do in Python, or Ruby? We
> need straight up advocacy, and that starts with everyone in this
> thread who *hasn't* done that yet.
>

These activities are good for hardcore developer advocacy. They are less
effective at swaying casual devs who can't code themselves out of a jam.

You might get some push back on [...]. Explain to them [...]
>

Education is important. It's also slow and expensive. In my experience,
"lead by example" is a more effective starting strategy than "show them the
light."

Anyway. I don't think it makes sense to solve problems that you don't
> have.


I've made a career out of solving other people's problems. It's why I'm an
expert tool maker and an awful astrophysicist. Programmers and
astrophysicists need each other to remain relevant.

Ideas are cheap, but it's an easy way to get people taking. And this kind
of discussion can lead to truly valuable insights as we share interests,
hopes, pain points, and coping mechanisms.

Eric

-- 
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] [ANN] Porting PAIP's Prolog interpreter from Common Lisp to Racket, 1st version

2017-10-13 Thread Luis Marcelo Rosso 
Hi all,

I am porting the Prolog interpreter shown in Peter Norvig's classic text on 
AI, "Paradigms of Artificial Intelligence Programming: Case Studies in 
Common Lisp 1st Edition", 
https://www.amazon.com/Paradigms-Artificial-Intelligence-Programming-Studies/dp/1558601910/,
 
also known as PAIP, in its chapter 11, "Logic Programming".

I have just ended its first version, corresponding to section 11.2, and 
shared:

   - the code at https://github.com/promesante/paip-racket/
   - the experience in 
   
https://promesante.github.io/2017/10/12/porting_paips_prolog_interpreter_from_common_lisp_to_racket/
   

Enhancement suggestions more than welcome.

Cheers

Luis M. Rosso
https://promesante.github.io/
https://github.com/promesante/

-- 
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] can't (require table-panel) today

2017-10-13 Thread Dmitry Pavlov 




#lang racket/gui
(require table-panel)

leads to:

standard-module-name-resolver: collection not found

Have you tried raco pkg install table-panel?

Best regards,

Dmitry

--
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: Naming conventions for private functions

2017-10-13 Thread Robby Findler 
Also: if you just don't `provide` a function from a module, then it
cannot be used outside. No naming conventions necessary.

Robby

On Fri, Oct 13, 2017 at 1:57 PM, Matthias Felleisen
 wrote:
>
>> On Oct 13, 2017, at 2:55 PM, David Storrs  wrote:
>>
>> On Fri, Oct 13, 2017 at 2:50 PM, David Storrs  wrote:
>>> Coming from a Perl background, I've long had a convention of naming
>>> private functions with a leading underscore, e.g. _do-the-thing.  Is
>>> there a standard Racket convention for this and, if so, what is it?
>>
>> Addendum:  I know that I can define functions inside the function for
>> which they are the helper, but my understanding is that if I do that
>> then the helper function is recompiled every time the parent function
>> is executed.
>>
>> (define (flurble args)
>>   (define (helper-func) ...do stuff...)
>>   (helper-func ...))
>>
>> (for ((i 1))
>>  (flurble i)) ; helper-func will be built 10,000 times, right?
>
>
> No it isn’t recompiled. But the run-time may allocate a closure a second time.
> Lambda lifting and similar techniques should avoid this but not necessarily in
> the current compiler.
>
> --
> 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.

-- 
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: Naming conventions for private functions

2017-10-13 Thread David Storrs 
On Fri, Oct 13, 2017 at 2:50 PM, David Storrs  wrote:
> Coming from a Perl background, I've long had a convention of naming
> private functions with a leading underscore, e.g. _do-the-thing.  Is
> there a standard Racket convention for this and, if so, what is it?

Addendum:  I know that I can define functions inside the function for
which they are the helper, but my understanding is that if I do that
then the helper function is recompiled every time the parent function
is executed.

(define (flurble args)
   (define (helper-func) ...do stuff...)
   (helper-func ...))

(for ((i 1))
  (flurble i)) ; helper-func will be built 10,000 times, right?

-- 
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] Naming conventions for private functions

2017-10-13 Thread David Storrs 
Coming from a Perl background, I've long had a convention of naming
private functions with a leading underscore, e.g. _do-the-thing.  Is
there a standard Racket convention for this and, if so, what is 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] can't (require table-panel) today

2017-10-13 Thread Geoffrey Knauth 
Is it me, or is it Friday the 13th?  (Or both?)

#lang racket/gui
(require table-panel)

leads to:

standard-module-name-resolver: collection not found
  for module path: table-panel
  collection: "table-panel"
  in collection directories:
   /Users/me/Library/Racket/snapshot/collects
   /Applications/Racket/Racket-v6.11.0.1/collects
   ... [165 additional linked and package directories] in: table-panel
  no package suggestions are available .

I click on Update Catalog and I get this:

get-all-pkg-details-from-catalogs: bad response from server
  url: 
https://www.cs.utah.edu/plt/snapshots/20170919-807ce8d495/catalog/pkgs-all?version=6.11.0.1
  response: #f

  (for-loop . #(struct:srcloc 
# 
299 2 11021 1759))
  (for-loop . #(struct:srcloc 
#
 
37 4 1350 2495))
  (pkg-catalog-update-local13 . #(struct:srcloc 
#
 
15 0 286 3561))
  (#f . #(struct:srcloc 
#
 
397 3 17564 3019))
  (for-loop . #(struct:srcloc 
#
 
90 7 3331 437))
  (.../more-scheme.rkt:261:28 . #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] Intro and projects inquiry

2017-10-13 Thread Hendrik Boom 
On Thu, Oct 12, 2017 at 09:07:48AM +1100, Daniel Prager wrote:
> Great topic!
> 
> Providing examples and tutorials around data analysis and visualisation in
> Racket (and filling gaps and simplifying) gets my vote.

The biggest problem wth almost all free software is documentation.
Sometimes it's simply absent; sometimes it's there but inadequaate, 
obsolete, or wrong; sometimes it's just impossible to find.  Even a 
Google search gets lost in a plethora of helpful hints posted 
randomly about the web so you won't find the authoritative stuff even 
when it exists.

-- hendrik

-- 
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] Multiple namespaces in Racket

2017-10-13 Thread Alexis King 
This is a cool demo! Unfortunately, I have been thinking about the
problem you describe since last night, and I am still totally stumped.
This is something that seems difficult or impossible to paper over with
more macros because #%require and #%provide are, ultimately, given
special treatment by the macroexpander (at least that is my
understanding), and the `expand` subform of #%provide is not something
that can be emulated as a derived concept.

At this point, though it is indisputably evil, it seems more feasible
to use some name mangling scheme than to expand to a submodule. That
would be, of course, deeply unsatisfying, so I would very much like to
have a better solution.

> On Oct 12, 2017, at 6:07 PM, Alex Knauth  wrote:
> 
> I just implemented this, and this is a problem, but the `all-from-out`
> form in general is an ever bigger problem, it's completely broken.
> 
> The first strategy is to just lift the provide form into a submodule,
> but `all-from-out` expects there to be a require in the *same* module,
> `all-from-out` always yells at you with the error, all-from-out: no
> corresponding require.
> 
> The second strategy is to try to resolve the `all-from-out` references
> in the pre-transformer using `expand-export`. However this is still
> broken for `all-from-out` because
> `syntax-local-module-required-identifiers` complains about "not
> currently transforming module provides."
> (syntax-local-transforming-module-provides? is false). All-from-out
> uses syntax-local-module-required-identifiers to determine what
> identifiers should be in it, and that needs to be called within a
> provide-transformer, not a provide pre-transformer.
> 
> To create a new lifted module I need to use a provide-pre-transformer,
> but to resolve all-from-out's properly I need to use a
> provide-transformer. Is there any way around this?
> 
> What I have so far:
> https://gist.github.com/AlexKnauth/b7d9f2e0af1c5b8e2186d6581b1f7e4d
> 
> Alex Knauth

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

Re: [racket-users] Intro and projects inquiry

2017-10-13 Thread 'Royall Spence' via Racket Users 
In this case, I'm thinking of the unfortunate JVM error messages from
Clojure. As far as I know, the main reason to suffer through Clojure's
attachment to the JVM is that no other Lisp has the same level of
support for web applications.

The second reason may be something about performance, but we can
probably close that gap with some different approaches. I'm specifically
thinking of taking a shot at a libev-based server like Common Lisp's Woo
for higher performance, although that would be a shot in the dark
because I don't understand the details affecting server performance
right now.

On Fri, Oct 13, 2017, at 11:55 AM, James wrote:
> 
> On Oct 13, 2017, at 9:44 AM, 'Royall Spence' via Racket Users wrote:
> 
> > Since we're bikeshedding here, I think we'd benefit from having a web
> > toolkit on par with Clojure's Luminus. We only need a few more packages,
> > a website documenting their interoperation, and a project skeleton to
> > create the same sort of experience with the benefit of better error
> > messages. I've already built one of the easy pieces (dotenv), and I'm
> > working on more more of them. Some of the things I'd like to include,
> > like server diagnostics, are a little over my head at the moment. I
> > intend to keep checking off the boxes, though, and have a
> > production-ready "framework" available sometime.
> 
> That's really good.  It's a pet peeve of mine that web sites and web
> tools often don't give, bury or suppress error messages.  My guess is
> that it started with the notion that you should suppress error messages
> to make SQL injection attacks harder.  I don't agree with that idea in
> the first place, much less in other areas besides opportunities for code
> injection.
> 
> -- 
> 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.

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

Re: [racket-users] Intro and projects inquiry

2017-10-13 Thread James 

On Oct 13, 2017, at 9:44 AM, 'Royall Spence' via Racket Users wrote:

> Since we're bikeshedding here, I think we'd benefit from having a web
> toolkit on par with Clojure's Luminus. We only need a few more packages,
> a website documenting their interoperation, and a project skeleton to
> create the same sort of experience with the benefit of better error
> messages. I've already built one of the easy pieces (dotenv), and I'm
> working on more more of them. Some of the things I'd like to include,
> like server diagnostics, are a little over my head at the moment. I
> intend to keep checking off the boxes, though, and have a
> production-ready "framework" available sometime.

That's really good.  It's a pet peeve of mine that web sites and web tools 
often don't give, bury or suppress error messages.  My guess is that it started 
with the notion that you should suppress error messages to make SQL injection 
attacks harder.  I don't agree with that idea in the first place, much less in 
other areas besides opportunities for code injection.

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

Re: [racket-users] Intro and projects inquiry

2017-10-13 Thread 'Royall Spence' via Racket Users 
In my experience, it means two seemingly opposite things that unify to
create bad software. On the one hand, it's an extreme conservatism and
fear of attempting new things. Don't try a new language, just keep using
PHP. Don't install the new PHP version with better features, it could be
risky. Don't use automated library management and deployment, we don't
understand it. Don't use git, it sounds scary.

On the other hand, this same attitude of underconfidence and low
ambition drives the adoption of dubious tooling. We cannot possibly be
smart enough to write our own application, so use this slow and
confusing web framework. Google and Facebook use these heavy Javascript
tools, so we'd better do that, too, on every single project. Who are we
to defy the "experts" in our field?

At least, that's been my experience in 10 years of web development. It's
perfectly fine to make mistakes, but I can't stomach the repetition.
Enough of my complaining, though.

Since we're bikeshedding here, I think we'd benefit from having a web
toolkit on par with Clojure's Luminus. We only need a few more packages,
a website documenting their interoperation, and a project skeleton to
create the same sort of experience with the benefit of better error
messages. I've already built one of the easy pieces (dotenv), and I'm
working on more more of them. Some of the things I'd like to include,
like server diagnostics, are a little over my head at the moment. I
intend to keep checking off the boxes, though, and have a
production-ready "framework" available sometime.

On Fri, Oct 13, 2017, at 08:25 AM, David Storrs wrote:
> On Fri, Oct 13, 2017 at 2:27 AM, Eric Griffis  wrote:
> > On Thu, Oct 12, 2017 at 9:31 AM David Storrs  wrote:
> >>
> 
> > Web dev culture is a bigger issue.
> >
> > Eric
> 
> How so?
> 
> -- 
> 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.

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

Re: [racket-users] Intro and projects inquiry

2017-10-13 Thread Matthias Felleisen 

So someone should organize a loosely connected group to port the core of Racket 
to the JVM: 
  — racket
  — the macro system 
  — all non-GUI libraries 
and provide a Clojure-style way to leverage the GUI libraries. 

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

Re: [racket-users] Intro and projects inquiry

2017-10-13 Thread David Storrs 
On Fri, Oct 13, 2017 at 2:27 AM, Eric Griffis  wrote:
> On Thu, Oct 12, 2017 at 9:31 AM David Storrs  wrote:
>>

> Web dev culture is a bigger issue.
>
> Eric

How so?

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

Re: [racket-users] Intro and projects inquiry

2017-10-13 Thread Eric Griffis 
On Thu, Oct 12, 2017 at 9:31 AM David Storrs  wrote:

> My suggestion would be that the single largest thing that would make
> Racket take off is if it could become a replacement for Javascript.


RacketScript Playground does not optimize tail calls. If it turned ES6
strict mode on, and if strict mode works as advertised, could RacketScript
leverage more Racket code to some advantage?

It's an interesting problem, but I doubt making Racket work better in the
browser would have the desired effect. Web dev culture is a bigger issue.

Eric

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