Re: [racket-users] Re: Racket2 possibilities

[Sam Tobin-Hochstadt]

On Mon, Jul 29, 2019 at 9:31 PM George Neuner  wrote:

> To me, TypedRacket feels much more like ML than like Dylan or Common
> Lisp.  Type inference is great - when it works. Coarse grained scope
> encompassing declarations are great - when you can figure out what
> they should be.  Reducing busywork and the cognative load on the
> programmer seems like it always should be a Good Thing.  But when
> inference fails and the declarations are unfathomable, and there is no
> easy way around the problem save by falling back to SLOW untyped code,
> then typing becomes a PITA.  To my thinking, there needs to be some
> middle ground - like CL's 'the' operator or Dylan's local annotations
> - that can disambiguate problems on the spot.

I'm not exactly sure what you're asking for here -- the CL type system
works very differently -- but local annotation is certainly possible
in Typed Racket. The `ann` form allows you to annotate any expression
at all, ie `(ann 17 Integer)`.

Sam

-- 
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/CAK%3DHD%2BbzHvs%2BNOUf7z6Gb77DWE7NwkYTjQsVH5nCFxJCzj%2BKvw%40mail.gmail.com.

[racket-users] Re: Racket2 possibilities

[George Neuner]

On Tue, 23 Jul 2019 15:18:26 -0700 (PDT), Atlas Atlas
 wrote:

>My personal big wish is "standard library" consistency and futures(like 
>more extended date-time functions).
>
>Another big wish is typed system. Typed racket looks like a BIG step 
>forward, and gives real benefits, it is shame it have not so much support.
>
>Another wish is more fluid transition between typed and untyped code. For 
>now it feels painful.

Agreed.  I actually liked Dylan's approach that, by default, code
should be latent typed.  Then annotation could be added incrementally
to elide runtime type tests and provide compile time diagnostics.

Of course, the compiler still should be analyzing the code as best it
can to avoid including unnecessary type tests in the first place.  I
don't know how well Racket fares currently in this regard, but the
good Common Lisp compilers can optimize away a lot of redundent type
tests.

And, of course, Common Lisp also allows some manual eliding of type
tests using the 'the' special operator.

Big difference was that Dylan's compiler would catch mismatched types
if they were statically known from the source, and if the compiler was
unsure about an expression containing mixed latent and manifest types,
it included the necessary runtime tests to catch problems.
OTOH, CL compilers trust the programmer and just elide any testing
when they see an annotated expression.


To me, TypedRacket feels much more like ML than like Dylan or Common
Lisp.  Type inference is great - when it works. Coarse grained scope
encompassing declarations are great - when you can figure out what
they should be.  Reducing busywork and the cognative load on the
programmer seems like it always should be a Good Thing.  But when
inference fails and the declarations are unfathomable, and there is no
easy way around the problem save by falling back to SLOW untyped code,
then typing becomes a PITA.  To my thinking, there needs to be some
middle ground - like CL's 'the' operator or Dylan's local annotations
- that can disambiguate problems on the spot.

YMMV,
George

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5u3vjehunjeui8m05okuf542ucgl49pmjj%404ax.com.

[racket-users] Re: Racket2 possibilities

[George Neuner]

On Tue, 23 Jul 2019 09:22:11 -0700 (PDT), Thomas Dickerson
 wrote:

>Since people are talking about running on different "VM" architectures, an 
>LLVM backend would be lovely and gives WebAssembly for free.

+1

>JVM support, on the other hand, seems like a particularly poor time 
>investment, since (1) there is no shortage of options for functional 
>programmers, and (2) the only real advantage of running on JVM is if you 
>can provide interoperability with the massive Java ecosystem, but that's 
>essentially incompatible with working around the JVM's bad architectural 
>decisions.
>The elephant in the room for any Scheme running on the JVM is that (a) 
>cross-function tail call elimination is incompatible with the security 
>model; (b) trampolining everything is bad for performance and, more 
>importantly, makes interoperability miserable (have fun writing all your 
>Java code that calls Racket code in manual CPS-style); and (c) throwing 
>everything into a massive state machine while-loop with gotos is both a 
>static analysis nightmare and breaks the JIT optimizer due to single-method 
>bytecode size restrictions.

Yes, JVM seems a rather poor target for a Scheme ... although Kotlin
does heroics converting tail recursion into interation to get around
(at least some of) the limitations.


OTOH, the dotNET runtime does support tail calling.  F#, at least,
uses that feature even if no other dotNET languages do.

Since dotNET Core now is supported on Linux, perhaps it should be
considered as a target instead of the JVM.

YMMV,
George

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/k8uuje5o61glv0hn2r0akilh2b1b19f0rh%404ax.com.

Re: [racket-users] a question related to bound-identifier=?

[Yongming Shen]

I think I found a case where id-a binds id-b when (would-bind? id-a id-b) 
returns #f:

(define-syntax bind-test0

  (lambda (stx)

(define id #'x)

(define shifted-id (syntax-shift-phase-level id -1))

(displayln (would-bind? id shifted-id))

(syntax-case stx ()

  [(_ e)

#`(let ([#,id e])

 (displayln #,shifted-id))])))

(bind-test0 100) would print #f then 100. However, if shifted-ld and id are 
swapped in (let ...), an undefined identifier error will be raised, which 
is consistent with the return value of (would-bind? ...). Is there a bug in 
how (let ...) handles identifiers with shifted phase levels?

Thanks,
Yongming


On Friday, July 26, 2019 at 7:07:49 AM UTC-4, Matthew Flatt wrote:
>
> At Thu, 25 Jul 2019 18:55:18 -0700 (PDT), Yongming Shen wrote: 
> > Based on my understanding, (bound-identifier=? id-a id-b) only returns 
> true 
> > if id-a would bind id-b AND id-b would bind id-a. Also based on my 
> > understanding, id-a will bind id-b doesn't imply that id-b will bind 
> id-a. 
> > So, if I only want to check whether id-a will bind id-b, which function 
> > should I use? 
>
> There's not a predicate like that right now (I guess only because we 
> haven't needed it). 
>
> Here's one way to implement the predicate: 
>
>  (define (would-bind? a b) 
>(subset? (list->set (hash-ref (syntax-debug-info a) 'context)) 
> (list->set (hash-ref (syntax-debug-info b) 'context 
>
> A built-in operation would work the same way, except that it could be 
> more efficient by not serializing scopes to a list in debugging 
> information and then converting the list back to a set. 
>
>
> 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/b1a999bb-cc3a-4da8-ae31-11e5a3bff7d6%40googlegroups.com.

Re: [racket-users] Can I use the macro stepper to debug an infinite expansion loop?

[Ryan Culpepper]

The macro stepper *should* pop up a dialog after a certain (large) 
number of steps and ask if you want to interrupt it and see the 
expansion up to that point. For example, try this:


  #lang racket
  (define-syntax-rule (m) (m))
  (m)

The dialog should show up in a second or two. It can't handle an 
individual transformer in an infinite loop, though.


If you're not seeing that dialog, you can try adjusting the limit by 
setting the 'MacroStepper:MacroStepLimit preference (the default is 
4) using preferences:set.


Ryan


On 7/29/19 8:38 PM, Leif Andersen wrote:

Unfortunately no. The macro stepper requires macros to fully expand
before it can let you step through them.

You can, however, use this `obs.rkt` file (attached) to debug macros
as they are expanding, and will print the current expanding syntax to
stdout. While not the most convenient thing in the world, I have been
able to use it to debug some pretty large and hairy macros.

(Thanks to Michael Ballentyne for giving me the original script.)

On 7/29/19, William J. Bowman  wrote:

Can I use the macro stepper to debug a bug in some code that seems to be
macro
expanding infinitely?
Is it in a sandbox to prevent infinite macro expansion or something?
It looks like DrRacket's background expander allows me to kill expansion
after a
short time, but when launching the macro stepper, it just hangs... or maybe
the
timeout is longer than I'm willing to wait.

--
William J. Bowman

--
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/20190729175903.GA22568%40williamjbowman.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/bcd83e86-e63e-c423-173e-492d771535ad%40ccs.neu.edu.

[racket-users] Symex: a DSL for symbolic expressions

[Siddhartha Kasivajhula]

Hi folks,
I've been lurking in these here forums for a little while now. Over the
years I've looked for the perfect language to implement toy projects in and
nothing seemed quite right. It wasn't until I found Racket a few months ago
that I felt I'd finally come home. Racket seems like an innovative, robust,
and inclusive community and I'm excited to see where things go, esp. with
the recent announcements.

Anyhow, that overdue introduction aside, I've written a DSL for editing
symbolic expressions, not in Racket but in Emacs Lisp, to support a
Vim-style editing interface for Emacs. If you're an Emacs user and
intrigued by modal interfaces, take a look:

https://github.com/countvajhula/symex.el

There's also a video overview and demo here:

https://www.youtube.com/watch?v=a5s1ScTx8Zk

... which features an example in Racket at around 12:05.

Towards the end of the presentation (around 50:07) I talk about a
generalization of modal user interfaces that has a "language-oriented
programming" flavor.

Enjoy,
-Sid

-- 
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/CACQBWFkUnN30qNzmMCW_15zqKyF%3DaWmf0npOU3BHZ4UuhjO%2BBQ%40mail.gmail.com.

Re: [racket-users] Can I use the macro stepper to debug an infinite expansion loop?

[Leif Andersen]

Unfortunately no. The macro stepper requires macros to fully expand
before it can let you step through them.

You can, however, use this `obs.rkt` file (attached) to debug macros
as they are expanding, and will print the current expanding syntax to
stdout. While not the most convenient thing in the world, I have been
able to use it to debug some pretty large and hairy macros.

(Thanks to Michael Ballentyne for giving me the original script.)

On 7/29/19, William J. Bowman  wrote:
> Can I use the macro stepper to debug a bug in some code that seems to be
> macro
> expanding infinitely?
> Is it in a sandbox to prevent infinite macro expansion or something?
> It looks like DrRacket's background expander allows me to kill expansion
> after a
> short time, but when launching the macro stepper, it just hangs... or maybe
> the
> timeout is longer than I'm willing to wait.
>
> --
> William J. Bowman
>
> --
> 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/20190729175903.GA22568%40williamjbowman.com.
>


-- 
~Leif Andersen

-- 
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/CAAVaeEAz0Q2piaCHeJE4beCzsHeqrvFXqFgDTjmRsrJzOWqd1A%40mail.gmail.com.


obs.rkt
Description: Binary data

[racket-users] Can I use the macro stepper to debug an infinite expansion loop?

[William J. Bowman]

Can I use the macro stepper to debug a bug in some code that seems to be macro
expanding infinitely?
Is it in a sandbox to prevent infinite macro expansion or something?
It looks like DrRacket's background expander allows me to kill expansion after a
short time, but when launching the macro stepper, it just hangs... or maybe the
timeout is longer than I'm willing to wait.

-- 
William J. Bowman

-- 
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/20190729175903.GA22568%40williamjbowman.com.

[racket-users] Re: Racket2 possibilities

[Atlas Atlas]

There is another interesting video 
https://www.youtube.com/watch?v=R3zEOsh8AnQ
I think that right approach for racket2 design is think in terms of 
neuroscience and cognitive science.

The things whats really mater is *consistency*, in style, in naming, in 
logic.
Another important thing is right balance in abstraction levels.

Very important thing is correlation in mental model, code syntax, and code 
semantics.

This is another reason against infix notation and C like syntax, we made 
lisp look like C but semantic remains the same - this will create huge 
problem of code understanding.
And this is the major problem for people who learning how to write 
programs, they struggling with infix notation a lot already, C like syntax 
is a mess, and introducing it to lisp language will create untold problems 
with understanding.

Lisp is great for representing time flow, it doesn't mess with code 
execution order, so this is strong side that must be used in advantageous 
way.

The weak side is data structures representation, relation between data, 
etc, this is where things can improve.
Introduction of typed racket is good in this sense. Because it allows to 
create bounds between functions and data.


понедельник, 29 июля 2019 г., 1:53:18 UTC+3 пользователь Atlas Atlas 
написал:
>
> Found this interesting video on GopherCon 
> https://www.youtube.com/watch?v=Ps3mBPcjySE 
> 
> Speaker raises questions about what a program code is and how it should 
> look
>

-- 
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/e82d26a8-5526-4c57-8531-99eb57d13acf%40googlegroups.com.

Re: [racket-users] Re: Racket2 possibilities

[Hendrik Boom]

On Sun, Jul 28, 2019 at 05:03:16PM -0700, Atlas Atlas wrote:
> пятница, 26 июля 2019 г., 23:35:45 UTC+3 пользователь Hendrik Boom написал:
> 
> >
> > One of the great things about Idris is its dependent types, and the 
> > way they can be used for (constructive) formal logic.  I was 
> > experimenting with them in the 80's. 
> >
> > To make them into a secure logic, however, you need limitations on 
> > recursion.  You need to effectively and provably show that all 
> > recursions terminate. 
> > That's a tall order for a language like Lisp.
> >
> 
> Perhaps to be practical security can be sacrificed.

What really kills security is the possibility of nonterminating type 
expressions. 

> 
>  
> 
> > I like Gambit's approach of easily mixing Lisp and C.  If only C 
> > implemented tail-recursions properly and had optional garbage 
> > collection. 
> >
> > Or maybe we need more low-level operations and data structures in 
> > Racket 2.  Modula 3, for example, manages to combine static 
> > type-security, garbage collection, systems-programming-style data 
> > structures, and an efficient code generator. 
> >
> 
> Functional structs works really bad for me, as well as classes.
> The main idea of struct is to simple combine some values together, in 
> simple way. (at leas as I see it)
> Every time I try to use classes or structs I ending trashing all and use 
> plane datatypes.
> I think racket classes can be useful for complex IO objects like databases, 
> GUI, or any UI, but I am not sure.
> In some places Racket shows tremendous possibilities and high complexity, 
> and at the same time leaves some obvious things with small attention.
> 
> About structs in regard of low level operations.
> In C#, structs have option to alight data in specific order, what makes 
> possible for very effective data packaging in some cases.
> For example I can encode in struct 4 bytes as 1 unsigned integer and have 
> access to each individual byte and to integer as whole.
> This can be really handy sometimes.

Yes.  Very handy.

-- hendrik

> 
> 
> In racket I just cannot think as before, in concepts of int16\32\64, this 
> also questions for me possibility of effective algorithms realization.

I still think in terms of limited size integers ehrn they are useful.  
I need types and operations that respect those types, have overflow 
detection, etc., and you I then use them if and only if they are 
appropriate for the application.  When the application diesn't require 
them I prefer integers that get as large as they need to be.

But in C/C++ programming on 32-bit machines, I find few cases where the 
available 32-bit integers don't suffice.  But I hate C's default of no 
overflow detection.  I like modulo-4294967296 arithmetic only when I 
specifically want it.

-- 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/6b83862a-6f5d-438a-8a59-abffa5e6a94b%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/20190729161525.q4o3j2peguc5itdd%40topoi.pooq.com.

Re: [racket-users] Re: Racket2 possibilities

[Mike G.]

On Fri, Jul 26, 2019 at 04:21:33PM -0400, Hendrik Boom wrote:
> On Fri, Jul 26, 2019 at 01:28:24AM -0700, Mike G. wrote:
> >  ??? Make a clear distinction between mutable and immutable data
> >  
> > Perhaps make everything immutable except for the contents of boxes 
> > (reminiscent of ML).  It would be a significant change, but I think that it 
> > would encourage functional programming and allow valuable optimizations. 
> 
> I'd very much like to avoid having to introduce extra references merely 
> to make something mutable.  It costs.

Fair enough.  Perhaps make everything immutable by default and add #:mutable 
and #:unique options to 'define' forms. 

> >  ??? Offer "unique" data
> 
> Like in Rust as well?

I am not familiar with Rust.
-- 
READ CAREFULLY. By accepting this material, you agree, on behalf of your 
employer, to release me from all obligations and waivers arising from any and 
all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.

-- 
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/20190729125243.GE26022%40flatline.halibut.com.

Re: [racket-users] Directory-specific installation of packages?

[James Geddes]

Alex, many thanks for the suggestions. 

I feel I’m putting too many obstacles in the way. (On the other hand, perhaps 
my situation is not so unusual.) I’m trying to make something work with as few 
barriers as possible, both for experienced (but non-Racket!) developers, and 
for Mac users who are still unsure about the command-line. 

> You can always create an executable (using "raco exe") and a distribution 
> (using "raco dist") which packs all dependencies in a single directory.  

This indeed was my original plan. But I worried about updates: `brew update` 
(or `raco pkg update`) are straightforward enough that people won’t balk. I 
think I can persuade people to do a one-off manual install process, but 
probably not repeated ones. 

In fact, as a first attempt I used homebrew to distribute an executable 
produced by `raco dist`. But to do this one has to go against the spirit of 
homebrew; and it’s therefore a pain to arrange.

> You could also provide a small shell script to update the PATH, which users 
> will have to run once for installation (I believe MacOS stores environment 
> variables in a plist?)

In the end, I went with the “please copy this shell command into a terminal” 
approach to have users set the PATH. Under MacOS, at least one mechanism to set 
the path is to create a file under /etc/paths.d/ whose contents are the 
required paths, so that’s what I did. (Paths set in one's bash config aren’t 
picked up by Mac GUI applications, not that that matters particularly in this 
case.) The only downside here is that the user needs to sudo the command. 

As I say, perhaps I’m just making up ad hoc objections, in which case I 
apologise. I’m reasonably happy with where I’ve ended up, though I remain 
hopeful that a more universal package manager will someday arise, perhaps along 
the lines of Nix (or Guix). 

Many thanks again,

James


-- 
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/171A1141-3D94-43ED-93FC-722E4105CDD6%40gmail.com.