Re: [racket-users] Re: Racket2 possibilities

[Yongming Shen]

I don't mind the parentheses. But I think Racket is kind of bloated and 
fragmented (I'm new to Racket, but this is the impression that I got so 
far). There are a lot of forms that are doing similar but slightly 
different things (e.g., the many let forms), and features that are not well 
integrated (the OO system comes to mind). I think it is amazing that all 
the features and forms that Racket provides can be reduced to a small set 
of core forms, but programmers don't write programs in the core forms, and 
I think it is the responsibility of the language designer to carefully 
craft a small set of forms and features that a programmer can use directly 
to solve most of the "ordinary programming problems" productively. 
Otherwise, personal extensions will flourish, and the ecosystem will be 
unnecessarily fragmented.

On Friday, August 2, 2019 at 6:44:41 AM UTC-4, Hendrik Boom wrote:
>
> On Fri, Aug 02, 2019 at 01:49:23AM -0700, Yongming Shen wrote: 
> > On the topic of making Racket 2 more appealing to new users. As a new 
> user 
> > myself, I have one (likely uninformed) suggestion: 
> > 
> > Design and promote a "boring core subset" that an experienced programmer 
> > can pick up easily and be as productive as when using an "ordinary 
> > programming language", without writing any macros. Macros are awesome, 
> > language-oriented programming is also awesome, if Racket 2 without them 
> can 
> > be as appealing (minus third-party library aspects) to programmers as 
> > Python/Ruby/Go/..., then Racket 2 plus them will certainly win hearts. 
>
> If you ignore the ability to define macros, isn't Racket already more 
> or less what you propose?  Except, perhaps, for all the parentheses? 
>
> -- 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/ddbbb0d0-89b5-4738-8eda-dc5dccdb6581%40googlegroups.com.

Re: [racket-users] Re: Racket2 possibilities

[Hendrik Boom]

On Fri, Aug 02, 2019 at 01:49:23AM -0700, Yongming Shen wrote:
> On the topic of making Racket 2 more appealing to new users. As a new user 
> myself, I have one (likely uninformed) suggestion:
> 
> Design and promote a "boring core subset" that an experienced programmer 
> can pick up easily and be as productive as when using an "ordinary 
> programming language", without writing any macros. Macros are awesome, 
> language-oriented programming is also awesome, if Racket 2 without them can 
> be as appealing (minus third-party library aspects) to programmers as 
> Python/Ruby/Go/..., then Racket 2 plus them will certainly win hearts.

If you ignore the ability to define macros, isn't Racket already more 
or less what you propose?  Except, perhaps, for all the parentheses?

-- 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/20190802104435.wpqn5vqbcmxzlfte%40topoi.pooq.com.

Re: [racket-users] Re: Racket2 possibilities

[George Neuner]

On 7/30/2019 12:59 PM, Atlas Atlas wrote:
вторник, 30 июля 2019 г., 4:40:40 UTC+3 пользователь Sam 
Tobin-Hochstadt написал:



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


The idea is you don't need to write this annotations. You can if you want.
In typed racket it is demand.
This became problem with untyped libraries, especially when they 
produce complex data. Or have complex macros.

Sometimes this catches you with iterations.

Simple example
(define (test-f a)
  (string-append a " okay"))
Typed-racket produces error: /"Type Checker: type mismatch expected: 
String given: Any"/ when type of _a_ can easily be inferred.

Solution is to infer type, or leave code untyped in some default way.

Another problem
require/typed - wraps code with contracts what have negative impact on 
performance, sometimes really bad one.

I just find current typed\racket condition unpractical.
I need for example to write my own untyped lib for using another 
untyped lib to simplify interfaces and make impact on performance more 
acceptable.


It seams what I am asking for here is unsound typing.


Latent typing ... what #lang Racket, Scheme and Lisp, etc. provide ... 
is not "unsound":  the data types are known and enforced, but the 
enforcement is at run time, and the result is that there are code size 
(type tests), data size (type tags or other metadata), and performance 
hits due to them.  The whole point of type declarations, type 
inferencing and so forth is to have the types known at compile time for 
sooner error diagnostics, and to increase performance by eliminating 
unneeded runtime testing.




Another option is to force! typed racket on all levels in all libs.

I am not so big expert in theory of language design..
There is some paper I found 
www.ccis.northeastern.edu/home/types/publications/gradual-dead/pre-treatment.pdf 
 
on this matter, called "Is Sound Gradual Typing Dead?" from 
Northeastern University, it highlights some of the problems in more 
scientific way.




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/130ed2ab-8b90-a0ad-3c27-fb7df73e6450%40comcast.net.

Re: [racket-users] Re: Racket2 possibilities

[George Neuner]

Hi Sam,

On 7/29/2019 9:40 PM, Sam Tobin-Hochstadt wrote:

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


'ann'  operand order puts the (possibly lengthy) code expression before 
the (typically much shorter) type declaration.  This is the reverse of 
the way Lisp does it, and, IMO, it makes 'ann' expressions harder to read.



I think Atlas nailed the crux of my issue: that Dylan and CL permit you 
to add manifest typing incrementally as you desire or see need, whereas 
TypedRacket requires at least some typing (of variables) right from the 
very beginning and then it continues to natter at you about things you 
don't necessarily care about  in the moment.


What I want is to be able to freely mix latent typed and manifest typed 
code, and not worry about crossing boundaries until performance 
considerations require that I do so.   That said, even though Common 
Lisp is closer to what I want - I don't use it precisely because it is 
Lisp ... I much prefer Scheme.


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/7a83ad6b-f724-e36f-a147-4930572e2694%40comcast.net.

Re: [racket-users] Re: Racket2 possibilities

[Atlas Atlas]

вторник, 30 июля 2019 г., 4:40:40 UTC+3 пользователь Sam Tobin-Hochstadt 
написал:

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

The idea is you don't need to write this annotations. You can if you want.
In typed racket it is demand.
This became problem with untyped libraries, especially when they produce 
complex data. Or have complex macros.
Sometimes this catches you with iterations.

Simple example 
(define (test-f a)
  (string-append a " okay"))
Typed-racket produces error: *"Type Checker: type mismatch expected: String 
given: Any"* when type of *a* can easily be inferred.
Solution is to infer type, or leave code untyped in some default way.

Another problem
require/typed - wraps code with contracts what have negative impact on 
performance, sometimes really bad one.
I just find current typed\racket condition unpractical.
I need for example to write my own untyped lib for using another untyped 
lib to simplify interfaces and make impact on performance more acceptable.

It seams what I am asking for here is unsound typing.

Another option is to force! typed racket on all levels in all libs.

I am not so big expert in theory of language design..
There is some paper I found 
www.ccis.northeastern.edu/home/types/publications/gradual-dead/pre-treatment.pdf
 
on this matter, called "Is Sound Gradual Typing Dead?" from Northeastern 
University, it highlights some of the problems in more scientific way.

-- 
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/bfaf043a-fe05-40a9-952b-6490f5b7d364%40googlegroups.com.

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.

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] Re: Racket2 possibilities

[Atlas Atlas]

пятница, 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.

 

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


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

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

Re: [racket-users] Re: Racket2 possibilities

[Neil Van Dyke]

If anyone wants to collaborate on doing something novel related to 
visual programming, I've previously done industry R work on that, and 
am open to serious academic or commercial efforts.


Atlas Atlas wrote on 7/28/19 6:53 PM:
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/941cc321-b948-8e5b-d6af-10695b3772ed%40neilvandyke.org.

Re: [racket-users] Re: Racket2 possibilities

[Hendrik Boom]

On Fri, Jul 26, 2019 at 02:41:31AM -0700, Sepand Meenu wrote:
> I have approached Racket mainly from a computational perspective (physics 
> and math), and I've found parentheses so far _not_ much of a distraction or 
> annoyance. Actually, as far as the parens reduce the amount of syntactical 
> complexity, I am in favour of them (compared to the nasty syntactical vexes 
> in C++, or probably all Algol-descendents).

a big problem with C is that some parentheses are semantically 
meaningful, rather than just indicating order of operations. This is 
especially confusing in notations for function types.

If it weren't for that, the parenthesis issues would be easy -- just 
insert a few extra ones any time you're not sure how things are 
grouped.

> I also like the 
> language-oriented-programming philosophy of Racket which makes syntax of 
> secondary importance. I think it is better to reduce the amount of parens 
> needed, rather than to eliminate them altogether in favour of an Algol-like 
> syntax. Racket2 might have even two possible syntaxes (Lisp and Algol 
> like), but I think syntactical patterns should _not_ be the first priority 
> of Racket2.

Racket already hs two syntaxes -- Scribble and Racket.

> 
> I think the most important task is to nurture the ecosystem of Racket: A 
> well-defined performant 'standard library' to be used in real-world 
> large-scale practical systems with high complexity (including tough 
> computations, concurrency, asynchronicity, etc.) in a safe, and proveably 
> correct manner. An expressive static typing is also one of my wishes, so 
> that a 'refined' Typed Racket becomes part of the standard; in this case, 
> one may learn from languages like Idris.

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.

> 
> Easy interoperability is very important at this stage (eg. with Python). 
> Having an LLVM backend is also very promising (unlike JVM) as Thomas 
> Dickerson mentioned.
> In general, due to my FORTRAN and C++ background, I am always very 
> concerned about performance, and looking forward to the Racket-on-Chez 
> project.

Likewise.

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.

-- 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/20190726203540.3uekgsg23r7g7lfy%40topoi.pooq.com.

Re: [racket-users] Re: Racket2 possibilities

[Hendrik Boom]

On Fri, Jul 26, 2019 at 01:28:24AM -0700, Mike G. wrote:
> Opinions are like belly buttons, and I'd like to show you two of mine (as in 
> that terrible Gene Roddenberry film). 
> 
> I very much like the overall goals of making Racket more consistent and more 
> generic.  They strike me as reforms of the language.  I wonder if adding 
> these features would be too far from the "spirit" of Racket. 
> 
>  • 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.

> 
>  • Offer "unique" data
> 
> As used in Clean and Idris, a unique value "is guaranteed to have at most one 
> reference to it at run-time, which means that it can safely be updated 
> in-place, reducing the need for memory allocation and garbage collection."

Like in Rust as well?

> 
> -- 
> 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/20190726082824.GB10803%40flatline.halibut.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/20190726202133.6fvzs76xxwjj2qug%40topoi.pooq.com.

Re: [racket-users] Re: Racket2 possibilities

[Mike G.]

Opinions are like belly buttons, and I'd like to show you two of mine (as in 
that terrible Gene Roddenberry film). 

I very much like the overall goals of making Racket more consistent and more 
generic.  They strike me as reforms of the language.  I wonder if adding these 
features would be too far from the "spirit" of Racket. 

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

 • Offer "unique" data

As used in Clean and Idris, a unique value "is guaranteed to have at most one 
reference to it at run-time, which means that it can safely be updated 
in-place, reducing the need for memory allocation and garbage collection."

-- 
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/20190726082824.GB10803%40flatline.halibut.com.

Re: [racket-users] Re: Racket2 possibilities

[Atlas Atlas]

Prefix notation is good.
What makes difficulties is mixed notations.
There how it looks:
(Math.Sin(1\(1 + Math.Exp(x * -1))) - Math.Pow((1\Math.Log(x - (r * -1))), 
3)) \ Math.Sqrt(Math.Pow(x + r, 2))
Add to this functions with more then 2 arguments.
Add to this iterations, and it will be complete hell.

In lisp, in another hand, you will get much cleaner expression, of course 
it is not ideal, but i don't known any better approach.


What I noticed, students often ignores how stupid computer is, and instead 
of setting goals for the computer they sets goals for themselves.
They try to avoid acceptance of abstract mathematical concept - what 
programming language is.
It is natural for human brains to avoid learning, and mismatch 
understanding with classification.

Students often have misunderstanding about what is function and what is 
function application, what is function arguments, *how data flow*, what is 
variable, and how it works.
They does not have feel of computer, of this soulless machine that crunches 
numbers.
They often have difficulty to understand that "defining" value means 
writing information to specific memory address.
So they see (define a (+1 2)) - not as command (add 1 to 2 and write result 
to memory cell witch refers as "a"), but as some purely syntactic statement 
separated from the machine. And they expect from it to act as such, what it 
doesn't do.

So I think basic syntax is not a problem at all.

What confuses first time is quotations especially quasiquote, but it is a 
trifle really.

What bothers me is that the (for) form is cumbersome, and with all the 
functionality it sometimes fails.
Lists have this nice functions like for-each map fold, all other 
collections should be subjects for this to.

So, in general, I think language need more of simple and practical 
constructs, and not big and complex monsters that can basically generate 
full syntax.


среда, 24 июля 2019 г., 5:26:32 UTC+3 пользователь Philip McGrath написал:
>
> I thought one of the most compelling parts of Matthew's proposal was at 
> around 
> 37:41 in the video 
> , when he said,
>
> I've seen students in my class genuinely struggle with just the syntax.
>
> I think it would be very useful to hear more (from Matthew or others) 
> about the struggles people have with s-expressions, both to understand the 
> motivations for a potential new surface syntax and to evaluate concrete 
> design ideas.
>
> As I've been reflecting over the last week, I realized that I have a 
> fairly deep knowledge of my own experiences learning new languages (or at 
> least I like to think I do …), and I know something about the experiences 
> of friends and colleagues, but my knowledge pretty quickly drops off after 
> that. Presumably, people who teach CS get to observe much larger samples. 
> Those in industry with experience on-boarding new employees might likewise 
> have useful perspectives.
>
> If a major goal for Racket 2, and the potential syntax change in 
> particular, is to reduce obstacles, I think it would help to understand 
> what the obstacles are, for various groups of people. 
>
> (For example, I would speculate that people who have experience 
> programming with Algol-like syntax may stumble at different points than new 
> programmers, and those comfortable with notation from math class may have 
> different expectations than those who are not—but that is just speculation. 
> In any case, such answers wouldn't dictate a particular decision, but they 
> could provide context to inform the decision-making process.)
>
> -Philip
>

-- 
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/f7a2417d-5b05-4deb-bbac-9a5b66b347c1%40googlegroups.com.

Re: [racket-users] Re: Racket2 possibilities

[Philip McGrath]

I thought one of the most compelling parts of Matthew's proposal was at around
37:41 in the video ,
when he said,

I've seen students in my class genuinely struggle with just the syntax.

I think it would be very useful to hear more (from Matthew or others) about
the struggles people have with s-expressions, both to understand the
motivations for a potential new surface syntax and to evaluate concrete
design ideas.

As I've been reflecting over the last week, I realized that I have a fairly
deep knowledge of my own experiences learning new languages (or at least I
like to think I do …), and I know something about the experiences of
friends and colleagues, but my knowledge pretty quickly drops off after
that. Presumably, people who teach CS get to observe much larger samples.
Those in industry with experience on-boarding new employees might likewise
have useful perspectives.

If a major goal for Racket 2, and the potential syntax change in
particular, is to reduce obstacles, I think it would help to understand
what the obstacles are, for various groups of people.

(For example, I would speculate that people who have experience programming
with Algol-like syntax may stumble at different points than new
programmers, and those comfortable with notation from math class may have
different expectations than those who are not—but that is just speculation.
In any case, such answers wouldn't dictate a particular decision, but they
could provide context to inform the decision-making process.)

-Philip


On Tue, Jul 23, 2019 at 4:18 PM 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.
>
> --
> 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/248536cd-bce7-4a49-ba29-f6a26de68459%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/CAH3z3gbU-SiTb6cMu%2BBOV%3D1zYTbELTL0fvHVJGy02J-NiziccA%40mail.gmail.com.

Re: [racket-users] Re: Racket2 possibilities

[Thomas Dickerson]

A couple thoughts, not particularly well-organized, but in a more 
accessible form here than just tweeting at Alexis.

In all this discussion of "parens-less LISP", I find it slightly odd that 
nobody has mentioned Logo yet. I'm ambivalent about surface syntax, but 
it's not like this is a revolutionary idea.

Since people are talking about running on different "VM" architectures, an 
LLVM backend would be lovely and gives WebAssembly for free.
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.

As someone who loves the Racket philosophy and 
language-oriented-programming, but who is also very interested in building 
large-scale practical systems, the single biggest obstacle to me using 
Racket over other functional languages (mostly Scala/Dotty) for personal 
projects is the lack of static typing (Typed Racket feels very much like a 
second-class citizen in the ecosystem).
My deepest dream would be for Racket2 to have static type-checking as the 
default, with opt-in Rust-like affine types for programs that need precise 
resource management.
Essentially any other outcome is "fine, I guess".

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

Re: [racket-users] Re: Racket2 possibilities

[Dexter Lagan]

  The second comment by slaymaker1907 is more progressive and closer to the 
truth no doubt. I merely meant to say that it does feel odd to take off parens 
off such a great scheme/lisp. But if there’s an elegant way to do it while 
maintaining all its power AND making it more approachable, all the better. If 
we could have the best of both worlds, Racket could appeal to a much wider 
audience.

  Like others have said, it also takes time for people to understand the 
potential, like it took me years to warm up to the idea of lisp in general, and 
months before I began really seeing a difference in my projects after picking 
Racket up. No matter what the outcome, this is exciting. 

  Simply contemplating the prospect of the evolution of such a powerful 
abstraction tool is exciting, and inspiring.

Dex

> On Jul 23, 2019, at 3:21 PM, Neil Van Dyke  wrote:
> 
> Dexter Lagan wrote on 7/23/19 3:32 AM:
>> Like the first HN comment said,
> 
> Currently 71 comments: https://news.ycombinator.com/item?id=20490423
> 
> FWIW, due to how the HN post was done, I don't know how representative the 
> comments are of professional developers.  The link was posted around 5pm 
> California time last night, and got 92 points, but had fallen off the front 
> page by early this morning Boston time.  (It could reappear this morning on 
> the front page, and get more representative comments, iff it organically gets 
> voted back up as Californians wake up.  But please no "brigade" voting, as 
> that's against the rules, bad form, and the admins can tell.)
> 
> -- 
> 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/6099bb78-7b2e-2749-0ed2-d19585a2f28b%40neilvandyke.org.

-- 
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/CD94ED47-9423-4348-9F97-560C4B9DAF69%40gmail.com.

Re: [racket-users] Re: Racket2 possibilities

[Neil Van Dyke]

Dexter Lagan wrote on 7/23/19 3:32 AM:

Like the first HN comment said,


Currently 71 comments: https://news.ycombinator.com/item?id=20490423

FWIW, due to how the HN post was done, I don't know how representative 
the comments are of professional developers.  The link was posted around 
5pm California time last night, and got 92 points, but had fallen off 
the front page by early this morning Boston time.  (It could reappear 
this morning on the front page, and get more representative comments, 
iff it organically gets voted back up as Californians wake up.  But 
please no "brigade" voting, as that's against the rules, bad form, and 
the admins can tell.)


--
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/6099bb78-7b2e-2749-0ed2-d19585a2f28b%40neilvandyke.org.

Re: [racket-users] Re: Racket2 possibilities

[Paulo Matos]

On 22/07/2019 22:42, Breck Yunits wrote:
> Aloha folks,
>
> I had to miss RacketCon this year as we have a new 6 month old at home
> and couldn't make the trek out.
>
> But I would love to lend my efforts to support the initiative to
> explore a Racket universe without parens. If folks out there are
> working on this, shoot me an email (bre...@gmail.com or
> yun...@hawaii.edu) and let me know how I can best help.
>
> I've been working on such a research effort since 2012. I call the
> notation Tree Notation http://treenotation.org/. Basically what I
> propose is splitting things up into 2 concepts: the base Tree Notation
> (which is 80% similar to I-Expressions), and then languages on top of
> that (which is where the #lang could come in).
>
> This syntax is less fragile
> (https://twitter.com/breckyunits/status/1153016840769007616) and makes
> 3 things much easier: program synthesis, data science, and visual
> programming.
>
> I think dropping parens would make a big difference and would be a
> great move for "Racket2"!
>
Thanks for the reference to your tree notation work.

Discussion is proceeding at a breath-taking pace. You might want to
enable notifications ('Watch') for
https://github.com/racket/racket2-rfcs, or you might not depending if
you want your like consumed by the #racket2 hash tag. ;)


> -Breck
>
>
>
> On Saturday, July 20, 2019 at 8:49:13 AM UTC-10, Matthew Flatt wrote:
>
> This message is intended as a prose form of what I said at RacketCon,
> but it includes some extra explanation triggered by the discussion so
> far. Where that happens, I apologize that it isn't in the form of a
> more direct response in the original thread.
>
> The Racket2 Idea
> 
>
> Racket's design and implementation is on solid ground, and from this
> point, it can continue to evolve and improve in many ways. No matter
> how Racket evolves, the community is committed to preserving what we
> have achieved: today's `#lang racket` programs will run in the
> future,
> and today's `#lang racket` modules can be used in future Racket
> programs. At the same time, the current language design may be
> close to
> a local maximum, and it's not in the nature of the Racket
> community to
> be satisfied with a local maximum.
>
> By starting all programs with `#lang`, we have created a path to leap
> from one peak of design to a different, higher peak without
> sacrificing
> the old one and while staying Rackety. Roughly, that's what we
> mean by
> "Racket2". The name "Racket2" stands for some language that builds on
> the current Racket technology and implementation, but that may not
> directly accommodate the same bindings and expression forms that
> appear
> in the body of a `#lang racket` module.
>
> Although we could literally write `#lang racket2` for modules in the
> new language, "Racket2" is normally understood as a placeholder for a
> more distinct name. As a matter of branding, perhaps the language
> would
> be called "Racket X" for some good X --- shortened to "X" in some
> contexts --- and Racket X program would be written with `#lang X`
> line
> at the top. Maybe the name depends on how different Racket2 turns out
> to be from Racket, so it makes sense to pick a name later.
>
> Venturing out from Racket's current peak opens a large space of
> possibilities, so the first step is to agree on a set of goals to be
> met by the next peak. The goals can serve as a starting point for
> developing roadmap for deciding on technical details in a follow-up
> process.
>
> Possible Language Changes
> -
>
> The Racket community has long discussed possibilities for Racket2.
> Here
> are a few potential changes from the wish list:
>
> * Rename functions to make the conventions more uniform, and make
>   better use of keyword arguments to reduce names and increase
>   consistency.
>
> * Change structures types to have more or fewer features.
>
> * Use generic datatypes (such as streams) pervasively, instead of
>   writing code that expects a particular concrete representation
> (such
>   as lists).
>
> * Make strings immutable by default (e.g., result of `format` or
>   `string-append`).
>
> * Adjust the semantics of common syntax forms, such as raising an
> error
>   on fall-through for `cond` or `match`, and change the meaning of
> some
>   primitives, such as making `integer?` mean "exact integer".
>
> * Make pattern matching more pervasive and available by default.
>
> * Change module, evaluation, and loading callbacks (e.g., protocol
> for
>   `current-module-name-resolver`) to improve errors and
> extensibility.
>
> More changes have been suggested, and no doubt many other changes
> would
> make sense. As a first 

Re: [racket-users] Re: Racket2 possibilities

[Dexter Lagan]

  Agreed, parentheses make manipulating code blocks a breeze. Also, I just 
realized I had confused Crystal with Julia in my initial rant. Made a fool of 
myself (again). I played with Julia when it reached 1.0 and liked the no-parens 
yet functional approach. It felt like a lisp in disguise, a bit like Python, 
but much cleaner. What I initially meant to say, apologies to Mr. King, is that 
a parent-less Racket2 would remind me of Julia. On the surface, at least! 
Crystal does have macros but that’s all it has in common with Julia and Racket.

  I did read the Honu paper and I agree: if there’s a way to transition, that’d 
be a very elegant one. Parentheses absolutely are a barrier of entry, and this 
would go a long way to make Racket less intimidating to non-lisp users. But is 
it worth the effort? Like the first HN comment said, ‘best way to break a good 
lisp is removing the parentheses’. I don’t think it’s that black, but 
there’s certainly some truth there.

Dex

> On Jul 23, 2019, at 12:17 AM, Zelphir Kaltstahl  
> wrote:
> 
> I just want to give one thought as input to this discussion and will admit, 
> that I did not read every (but some) of the posts above.
> 
> When I write code in Racket or Scheme, I mostly like the parentheses, as they 
> make writing the code easy. I can very easily select a block and move it 
> around, without introducing any syntax errors. I can also quickly see what 
> the scope of something is, what other expression it is in. I don't get these 
> things from languages without this many parentheses or without s-expression 
> syntax. I need my parentheses as markers for my cursor to quickly jump 
> around. It is the most pleasant code typing experience I've ever had. So when 
> considering to move away from parentheses, please also consider the burden 
> that those parentheses take away from the person writing the code. When I 
> edit for example Python code, things are not clear when moving around code. 
> This is worse in Python than in other languages, which at least have curly 
> braces (but usually some other annoying deficiencies). If there was a move 
> away from this many parentheses (read markers for my cursor), it would have 
> to provide equal editability, for it to be attractive to me. A design based 
> on indentation or something like that is not going to cut it for me. And what 
> else would be used as start and end markers for expressions? Wouldn't that in 
> essence just be another form of "parentheses", just looking different? How 
> would any editor know, where an expression starts and ends for easy selection 
> and moving around, if there were no such markers? So far I got no idea how 
> that could be done without introducing loads of new constraints about how you 
> can nest expressions into the language. So it beats me. Maybe my imagination 
> in this area is still somewhat limited.
> 
> Just my 2c.
> -- 
> 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/bf0b5dd1-8802-4c78-af7a-4231ae30ad60%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/6994654B-255A-4A0A-AF63-2702EFD67B75%40gmail.com.

Re: [racket-users] Re: Racket2 possibilities

[Breck Yunits]

Hi Zelphir,

Your concerns are absolutely warranted.

>From what I've seen there is no advantage that editors can give you with
parens, that they can't do better without parens, *given that you've
written loads of tests and done the grunt work to make that happen*.

Hence, it doesn't make sense to advocate for removing parens for Racket2
until all the code and tests are written for the different editors that
make the parens-less experience fantastic, and folks can compare the 2 side
by side. So if folks are working toward that, please let me know as I'd
love to help out.

-Breck

On Mon, Jul 22, 2019 at 12:17 PM Zelphir Kaltstahl <
zelphirkaltst...@gmail.com> wrote:

> I just want to give one thought as input to this discussion and will
> admit, that I did not read every (but some) of the posts above.
>
> When I write code in Racket or Scheme, I mostly like the parentheses, as
> they make writing the code easy. I can very easily select a block and move
> it around, without introducing any syntax errors. I can also quickly see
> what the scope of something is, what other expression it is in. I don't get
> these things from languages without this many parentheses or without
> s-expression syntax. I need my parentheses as markers for my cursor to
> quickly jump around. It is the most pleasant code typing experience I've
> ever had. So when considering to move away from parentheses, please also
> consider the burden that those parentheses take away from the person
> writing the code. When I edit for example Python code, things are not clear
> when moving around code. This is worse in Python than in other languages,
> which at least have curly braces (but usually some other annoying
> deficiencies). If there was a move away from this many parentheses (read
> markers for my cursor), it would have to provide equal editability, for it
> to be attractive to me. A design based on indentation or something like
> that is not going to cut it for me. And what else would be used as start
> and end markers for expressions? Wouldn't that in essence just be another
> form of "parentheses", just looking different? How would any editor know,
> where an expression starts and ends for easy selection and moving around,
> if there were no such markers? So far I got no idea how that could be done
> without introducing loads of new constraints about how you can nest
> expressions into the language. So it beats me. Maybe my imagination in this
> area is still somewhat limited.
>
> Just my 2c.
>
> --
> 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/bf0b5dd1-8802-4c78-af7a-4231ae30ad60%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/CAOgHByu0RLROGMvdXxO0uCTDGN69u%3DgAp8c%2B9vtiSzSPRF91Dg%40mail.gmail.com.

Re: [racket-users] Re: Racket2 possibilities

[Neil Van Dyke]

Maria Gabriela Guimarães wrote on 7/22/19 10:52 AM:
> I experimented with various scheme in browser intrepred via 
JavaScript and compiled to wasm both are not good enough.


Insufficient implementations I suppose, or wasm misses features 
important for a Scheme ...


What Maria said.  WASM (not JS) now seems the place for us to focus, for 
performance.  It's a little early for Schemes in WASM, and I don't know 
whether the best WASM methods for Schemes/Racket have yet been 
attempted, and if they'd have all the support in WASM they might want.


Once WASM is all ready, JS presumably will remain in the standards and 
in some use, but might actually become unpopular.  The browser 
developers have their own favored non-JS languages, and also heavily 
influence Web standards, so they might eventually make it so that JS can 
be all but eliminated.  And then, given that technical possibility, 
there's Web development culture: a hottest framework can become shunned 
within a year or two (and there's also rampant age discrimination, so 
many industry-savvy people truncate their older experience), so, 
half-seriously, I wouldn't be too surprised if JS becomes uncool to even 
admit knowing.


i don't know whether someone has yet dug into making a really performant 
WASM backend for Racket, and I'd guess people might want to wait for any 
interfaces/models from the Chez backend work to be about finalized first.


In the meantime, hopefully someone who needs the same WASM features such 
backend for Racket will want, has eaten or will eat the beetle grubs, in 
time: 
https://www.mail-archive.com/racket-users@googlegroups.com/msg36362.html


A little earlier context on WASM for Racket: 
https://www.mail-archive.com/racket-users@googlegroups.com/msg35803.html


There are pros about WASM, Web standards, influences, etc., and I 
suggest we want to keep cross-platform (not just Web browser, nor 
primarily Web browser) focus, for long-term reasons.  But it would be 
immediately very useful for many of us, if/when Racket gets a good WASM 
backend.  And, given the possible disruption of JS that I speculate 
about above, maybe that will also be an opportunity to bring Racket 
goodness to a lot more people.


--
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/e573db75-573e-f99a-d191-df1e6a944df8%40neilvandyke.org.

Re: [racket-users] Re: Racket2 possibilities

[Paulo Matos]

On 22/07/2019 16:52, Maria Gabriela Guimarães wrote:
> > I experimented with various scheme in browser intrepred via
> JavaScript and compiled to wasm both are not good enough.
>
> Insufficient implementations I suppose, or wasm misses features
> important for a Scheme ...
>
Someone wanting to take this on might gain inspiration from:
https://github.com/google/schism

> Em segunda-feira, 22 de julho de 2019 15:33:59 UTC+1, amz3 escreveu:
>
>
>
> On Monday, July 22, 2019 at 4:26:04 PM UTC+2, Mário Guimarães wrote:
>
>
> > And the JVM in browsers has been thoroughly supplanted by
> Javascript. 
>
> I missed another VM: Racket2 should also target WebAssembly.
>
>
> I experimented with various scheme in browser intrepred via
> JavaScript and compiled to wasm both are not good enough.
>
> -- 
> 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/9b5cdf22-8d78-42d8-86a0-bf5893a26f74%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/23fd9641-49b5-4784-a705-7c2ffcd9e6fb%40linki.tools.

Re: [racket-users] Re: Racket2 possibilities

[Maria Gabriela Guimarães]

> I experimented with various scheme in browser intrepred via JavaScript 
and compiled to wasm both are not good enough. 

Insufficient implementations I suppose, or wasm misses features important 
for a Scheme ...

Em segunda-feira, 22 de julho de 2019 15:33:59 UTC+1, amz3 escreveu:
>
>
>
> On Monday, July 22, 2019 at 4:26:04 PM UTC+2, Mário Guimarães wrote:
>>
>>
>> > And the JVM in browsers has been thoroughly supplanted by Javascript. 
>>
>> I missed another VM: Racket2 should also target WebAssembly.
>>
>
> I experimented with various scheme in browser intrepred via JavaScript and 
> compiled to wasm both are not good enough. 
>

-- 
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/9b5cdf22-8d78-42d8-86a0-bf5893a26f74%40googlegroups.com.

Re: [racket-users] Re: Racket2 possibilities

[amz3]

On Monday, July 22, 2019 at 4:26:04 PM UTC+2, Mário Guimarães wrote:
>
>
> > And the JVM in browsers has been thoroughly supplanted by Javascript. 
>
> I missed another VM: Racket2 should also target WebAssembly.
>

I experimented with various scheme in browser intrepred via JavaScript and 
compiled to wasm both are not good enough. 

-- 
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/d0d2ba3e-057a-46d4-bfb6-77a915bedd09%40googlegroups.com.

Re: [racket-users] Re: Racket2 possibilities

[Mário Guimarães]

> And the JVM in browsers has been thoroughly supplanted by Javascript. 

I missed another VM: Racket2 should also target WebAssembly.

segunda-feira, 22 de Julho de 2019 às 14:44:06 UTC+1, Hendrik Boom escreveu:
>
> On Mon, Jul 22, 2019 at 02:19:39AM -0700, Maria Gabriela Guimarães wrote: 
> ... 
> > 
> > I have mentioned this one, and will repeat again: 
> > 
> > *Make Racket become Language-Oriented Programming on the JVM, the 
> ErlangVM, 
> > and perhaps other mainstream VMs.* 
>
> And the JVM in browsers has been thoroughly supplanted by Javascript. 
> The designers of Javaascript originally planned to put a Lisp on the 
> browser (possibly even a Scheme?) but were forced to give it a C-like 
> syntax. 
> Is Javascript the kind of Scheme-without-parentheses we're looking for? 
> Perhaps not; it isn't a design-your-own-language system. 
>
> -- hendrik 
>
> > 
> > Failing to target these VMs and you will be in the next 5 years asking 
> > again why Racket 2 is still hardly adopted. 
> > 
> > I can't say more regarding Racket's adoption strategy. 
> > 
> > Thanks 
> > Mário Guimarães 
>

-- 
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/839c8ce2-e7d8-4cfd-ae27-fdea9268eabd%40googlegroups.com.

Re: [racket-users] Re: Racket2 possibilities

[Hendrik Boom]

On Mon, Jul 22, 2019 at 02:19:39AM -0700, Maria Gabriela Guimarães wrote:
...
> 
> I have mentioned this one, and will repeat again:
> 
> *Make Racket become Language-Oriented Programming on the JVM, the ErlangVM, 
> and perhaps other mainstream VMs.*

And the JVM in browsers has been thoroughly supplanted by Javascript.
The designers of Javaascript originally planned to put a Lisp on the
browser (possibly even a Scheme?) but were forced to give it a C-like syntax.
Is Javascript the kind of Scheme-without-parentheses we're looking for?
Perhaps not; it isn't a design-your-own-language system.

-- hendrik

> 
> Failing to target these VMs and you will be in the next 5 years asking 
> again why Racket 2 is still hardly adopted.
> 
> I can't say more regarding Racket's adoption strategy.
> 
> Thanks
> Mário Guimarães

-- 
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/20190722134403.hqlxcnz35u2okqmh%40topoi.pooq.com.

Re: [racket-users] Re: Racket2 possibilities

[Dexter Lagan]

  I'm not going over why s-expressions are the way to go, mr. Rivest did it
best in his 1997 MIT doc:

https://people.csail.mit.edu/rivest/Sexp.txt

  A parens-less Racket2 would become Crystal. And I don't think we need yet
another functional parens-less language. We already have Haskell (hard to
read) and Crystal (weird half-commercial proposition that won't produce
binaries without major hacks). I say we keep the parens but make them even
less intrusive. Newlisp may be an ugly hack, but its simplified forms and
anaphoric vars are very nice to use. For example:

http://www.newlisp.org/downloads/newlisp_manual.html#if

Dex


On Mon, Jul 22, 2019 at 5:11 AM Ray Racine  wrote:

> Over the years I have loved Racket ... except for those parens ... if
> only.   I don't know when it happened but one day parens and I made a peace
> treaty, mind melded, became enlightened or just got tired of fighting, but
> right now I can't see a Racket without parens (s-exps). I have, in fact,
> grown rather fond of them.
>
> There is the bottom up approach to grow Racket2 from examples and snippets
> of syntax all to be compared and endlessly debated.
>
> Rhetorical mullings from the top down perspective is interesting.
>
> Assume a Racket2 will not be another Ruby or Python as Racket is a BIG
> language and could not be compressed down to a simplistic Python or simple
> lisp without parens Ruby.  And what is the point of Racket2 being a Ruby or
> Python wanna-be anyway?  Would the world move to a better Python/Ruby?
>
> Assume it will not be some variation of a Swift, Java or C#.
>
> If moving from s-exp to traditional in-fix and f(x,y,z) function
> application makes sense to seek wider adoption, would not moving from
> functional to imperative also make sense? After all, all the popular
> languages are imperative, therefore, to enhance the likelihood of wide
> adoption should Racket2 be imperative as well?
>
> But then wouldn't Racket2 be Algol2 or Ada2 with macros?
>
> If it stays functional and expression based with macros then isn't Racket2
> then Dylan2?
>
> Of the three axioms of Racket2, the f(x,y,z) proscription prohibits some
> of the cleaner syntax out there as used in SML and Haskell.  Is it a hard
> requirement to ensure full macro support can happen?
>
> If Racket2 moves to be even more functional in thrust, drops the f(x,y,z)
> proscription and adopts currying then isn't Racket2 a polished up nextgen
> SML2?
>
> Maybe a nextgen SML2 for semantics and typing but with the lighter Haskell
> syntax (no laziness)?
>
> What will be the magic twist for widespread adoption that Algol, Ada,
> Dylan, SML, Haskell and s-exp Racket, all with quality implementations,
> failed to achieve?
>
> How much of a languages adoption success is just shear dumb luck, the
> right place at the right time independent of the languages overall quality
> and capability? Does Javascript even need to mentioned here?
>
> Should we cover all possible bases and make Racket and its "make
> languages" core a nextgen DotNet and put together a whole suite of
> languages, a Lisp like, an Algo like, a SML like, a Haskell like, a
> Java/Swift like, an Erlang like, ... all interoperable.   If that all of
> that happened tomorrow by magic would the world embrace Racket(2...).
>
>
>
>
>
>
>
>
>
> --
> 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/c8abfd8b-3304-4ed5-9e23-bf2f1d7da8cb%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/CACUENr%2BPQq8DCuUBcuZOL37QD2ByypNiu0rx3MagvTOY0zxDjg%40mail.gmail.com.