Re: [racket-users] Why do single-form modules behave differently?

2021-01-02 Thread Michael MacLeod
Oops, sorry about interpreting your question wrong. Unfortunately I don't
know the answer to your actual question.

On Sat, Jan 2, 2021, 10:24 PM Sage Gerard  wrote:

> I know about that. I asked why it was designed that way.
>
>
> Sent from ProtonMail mobile
>
>
>
>  Original Message 
> On Jan 3, 2021, 12:18 AM, Michael MacLeod < michaelmmacl...@gmail.com>
> wrote:
>
>
> There's an edge case of 'module' when only one form is provided which
> results in that form being partially expanded to determine if such
> expansion would lead to a #%plain-module-begin form. Otherwise (more than
> one form provided) they are wrapped in #%module-begin with no partial
> expansion occurring.
>
> I think this might be causing the discrepancy you witnessed.
>
> From the docs (https://docs.racket-lang.org/reference/module.html):
>
> If a single form is provided, then it is partially expanded in a
> module-begin context. If the expansion leads to #%plain-module-begin, then
> the body of the #%plain-module-begin is the body of the module. If partial
> expansion leads to any other primitive form, then the form is wrapped with
> #%module-begin using the lexical context of the module body; this
> identifier must be bound by the initial module-path import, and its
> expansion must produce a #%plain-module-begin to supply the module body.
> Finally, if multiple forms are provided, they are wrapped with
> #%module-begin, as in the case where a single form does not expand to
> #%plain-module-begin.
>
> (This response was adapted from one of my earlier replies to the mailing
> list. Search racket-users for "perplexed by macro-expansion behavior near
> #%module-begin" for more context).
>
> Best,
> Michael
>
> On Sat, Jan 2, 2021 at 8:26 PM Sage Gerard  wrote:
>
>> Why does Racket handle modules with exactly one form differently?
>>
>> I ran into a bug where modules in my module language won't expand if the
>> modules have exactly one form, so I'm just curious.
>>
>> (Wild guess: It's Racket's way of checking for a shortcut to end
>> expansion earlier)
>>
>> *~slg*
>>
>>
>> --
>> 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/OVvZ0OK4_PfyvXCWfuvzDWBM5-ellmDvNmWchVmsCwAJb_rbSZkCkyraakcGsEMSCl2BsLsWtMXFhQcXY75IKhYiYYGQQEI7lVXLgGBbTCc%3D%40sagegerard.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/CACehHmBvs5KK4vQmwio93D1NZ9hTOoSv-Qkm8XOjF%2B4JWDOiHg%40mail.gmail.com.


Re: [racket-users] Why do single-form modules behave differently?

2021-01-02 Thread Sage Gerard
I know about that. I asked why it was designed that way.

Sent from ProtonMail mobile

 Original Message 
On Jan 3, 2021, 12:18 AM, Michael MacLeod wrote:

> There's an edge case of 'module' when only one form is provided which results 
> in that form being partially expanded to determine if such expansion would 
> lead to a #%plain-module-begin form. Otherwise (more than one form provided) 
> they are wrapped in #%module-begin with no partial expansion occurring.
>
> I think this might be causing the discrepancy you witnessed.
>
> From the docs (https://docs.racket-lang.org/reference/module.html):
>
> If a single form is provided, then it is partially expanded in a module-begin 
> context. If the expansion leads to #%plain-module-begin, then the body of the 
> #%plain-module-begin is the body of the module. If partial expansion leads to 
> any other primitive form, then the form is wrapped with #%module-begin using 
> the lexical context of the module body; this identifier must be bound by the 
> initial module-path import, and its expansion must produce a 
> #%plain-module-begin to supply the module body. Finally, if multiple forms 
> are provided, they are wrapped with #%module-begin, as in the case where a 
> single form does not expand to #%plain-module-begin.
>
> (This response was adapted from one of my earlier replies to the mailing 
> list. Search racket-users for "perplexed by macro-expansion behavior near 
> #%module-begin" for more context).
>
> Best,
> Michael
>
> On Sat, Jan 2, 2021 at 8:26 PM Sage Gerard  wrote:
>
>> Why does Racket handle modules with exactly one form differently?
>>
>> I ran into a bug where modules in my module language won't expand if the
>> modules have exactly one form, so I'm just curious.
>>
>> (Wild guess: It's Racket's way of checking for a shortcut to end expansion 
>> earlier)
>>
>> ~slg
>>
>> --
>> 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/OVvZ0OK4_PfyvXCWfuvzDWBM5-ellmDvNmWchVmsCwAJb_rbSZkCkyraakcGsEMSCl2BsLsWtMXFhQcXY75IKhYiYYGQQEI7lVXLgGBbTCc%3D%40sagegerard.com](https://groups.google.com/d/msgid/racket-users/OVvZ0OK4_PfyvXCWfuvzDWBM5-ellmDvNmWchVmsCwAJb_rbSZkCkyraakcGsEMSCl2BsLsWtMXFhQcXY75IKhYiYYGQQEI7lVXLgGBbTCc%3D%40sagegerard.com?utm_medium=email_source=footer).

-- 
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/KIgkgUi46OgANOqlif1csB0xaQQR2Z9I-jSlYmszXSGWsyFmt_XYpEPAzD7F_XguhZKv8OyU_EIA2pTxn8yvivQIj5hjyVzqgIpX9iNNs7o%3D%40sagegerard.com.


Re: [racket-users] Why do single-form modules behave differently?

2021-01-02 Thread Michael MacLeod
There's an edge case of 'module' when only one form is provided which
results in that form being partially expanded to determine if such
expansion would lead to a #%plain-module-begin form. Otherwise (more than
one form provided) they are wrapped in #%module-begin with no partial
expansion occurring.

I think this might be causing the discrepancy you witnessed.

>From the docs (https://docs.racket-lang.org/reference/module.html):

If a single form is provided, then it is partially expanded in a
module-begin context. If the expansion leads to #%plain-module-begin, then
the body of the #%plain-module-begin is the body of the module. If partial
expansion leads to any other primitive form, then the form is wrapped with
#%module-begin using the lexical context of the module body; this
identifier must be bound by the initial module-path import, and its
expansion must produce a #%plain-module-begin to supply the module body.
Finally, if multiple forms are provided, they are wrapped with
#%module-begin, as in the case where a single form does not expand to
#%plain-module-begin.

(This response was adapted from one of my earlier replies to the mailing
list. Search racket-users for "perplexed by macro-expansion behavior near
#%module-begin" for more context).

Best,
Michael

On Sat, Jan 2, 2021 at 8:26 PM Sage Gerard  wrote:

> Why does Racket handle modules with exactly one form differently?
>
> I ran into a bug where modules in my module language won't expand if the
> modules have exactly one form, so I'm just curious.
>
> (Wild guess: It's Racket's way of checking for a shortcut to end expansion
> earlier)
>
> *~slg*
>
>
> --
> 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/OVvZ0OK4_PfyvXCWfuvzDWBM5-ellmDvNmWchVmsCwAJb_rbSZkCkyraakcGsEMSCl2BsLsWtMXFhQcXY75IKhYiYYGQQEI7lVXLgGBbTCc%3D%40sagegerard.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/CACehHmC0ZMqoGv8SF8jiEkLJfE4SL1SKsCuJUT1W2qYDORo19Q%40mail.gmail.com.


[racket-users] Why do single-form modules behave differently?

2021-01-02 Thread Sage Gerard
Why does Racket handle modules with exactly one form differently?

I ran into a bug where modules in my module language won't expand if the
modules have exactly one form, so I'm just curious.

(Wild guess: It's Racket's way of checking for a shortcut to end expansion 
earlier)

~slg

-- 
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/OVvZ0OK4_PfyvXCWfuvzDWBM5-ellmDvNmWchVmsCwAJb_rbSZkCkyraakcGsEMSCl2BsLsWtMXFhQcXY75IKhYiYYGQQEI7lVXLgGBbTCc%3D%40sagegerard.com.


Re: [racket-users] Unsafe structs

2021-01-02 Thread Robby Findler
On Sat, Jan 2, 2021 at 4:34 PM Dominik Pantůček <
dominik.pantu...@trustica.cz> wrote:

> Hello Racketeers (and Robby especially)!
>
> On 22. 12. 20 1:30, Robby Findler wrote:
> > Is Typed Racket able to prove that your use of unsafe accessors is
> > actually safe?
>
> Short answer: YES.
>
> One question for a start: And what now?
>
>
That's great! (And I can sympathize about the sarcastic thank you-- getting
a machine to verify a proof of something you know to be true is really a
lot of work!)

As for what now, my hope was that if TR could provide that your uses were
good then you could rely on TR to follow up with the actual optimizations.
Did you find that to be the case? I see you had to give up on the
parallelism for other reasons so I guess there is still a ways to go. I'm
not going to recommend that you follow this path further, but I guess that
if you did there would be grateful people, perhaps starting with Sam.

Robby

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


Re: [racket-users] Unsafe structs

2021-01-02 Thread Dominik Pantůček
Hello Racketeers (and Robby especially)!

On 22. 12. 20 1:30, Robby Findler wrote:
> Is Typed Racket able to prove that your use of unsafe accessors is
> actually safe? 

Short answer: YES.

One question for a start: And what now?

Disclaimer: The following text is by no means intended as critique but
rather it should be viewed as a summary of my experience with typing
middle-sized project in two weeks.

Long rant follows.

When Ben sent the Typed Racket Survey[1] here, my experience with TR was
only minimal. I worked with the math/matrix and basically focused on
performance gains it might yield. So I honestly filled-in whatever I
knew. Now I know much more. Hope it will help.

Let's first sum up where TR helped enormously and actually surprised me
VERY pleasantly:

* Finding cases of (when ...) and similar # returning constructs
where values are to be returned and probably error should be raised
instead of returning nothing. Although the actual erroneous return never
happened in the code in question, those constructs were meant to ensure
correct value is returned... Probably some leftovers from the early days
of this project. TR spotted them immediately.

* Finding improper usage of #f for missing information. When the program
expects some value, #f is not the right choice of fallback value. It is
the right one if you want to use it as a condition. Again, these were
leftovers from various experiments - mostly when loading data. TR to the
rescue again.

* Unintended use of default procedure arguments - nice and unexpected!

And now for the worse part. TR rough edges:

* Higher-order procedures and polymorphic functions in all imaginable
combinations. That was a total disaster. Yes, the documentation clearly
states that - but typing any code using these is like trying to break a
badly designed cipher. Irregularities here and there. Sometimes simple
`inst' was enough. Sometimes casting both the function and the arguments
was necessary. The biggest trouble is that the error messages are very
cryptic and sometimes even do not point to the offending construct but
only the module file. I will provide MWE to show this if someone wants
to look into it.

* Struct: Missing struct generics - when porting code that relies on
them, there's not much that can be done.

* Math: there really is just a natural logarithm and no logarithm with
arbitrary base? Yes, one-line to implement, but why?

* Math/Fixnums/Flonums: All fx+/-/*/... accept two arguments only. No
unary fl-, no variadic-argument fl+ or fxior (this one hurt the most).

* unsafe/ops: unsafe-vector-* resisted a lot - until I just gave up and
require/typed it for my particular types. Maybe casting would help, but
the error messages were different to the classical problems of the
polymorphic functions in TR.

* Classes: My notes say "". Which roughly says it
all. Although I managed to back down to only using bitmap% class,
properly typing all procedures using it was a nightmare. By properly I
mean "it compiles and runs".

* with-input-from-file does not accept Path or String, only Path-String
and the conversion rules are either missing or strange at best.
Basically I ended up with just converting to String and casting to
Path-String to make everything work.

* with-input-from-file also revealed that procedure signatures as types
can be very tricky - just passing `read' was not possible, because it
accepts some optional arguments. Wrapping it in thunk helped though.

* order of definitions matters. Not that this is unexpected, it is just
strange when working with larger code-base where it didn't matter.
Actually the error messages were helpful here.

* Type annotations of procedures with variadic arguments. The only place
where I had to put annotations outside of the procedure definition. It
is nothing super-problematic, but it feels inconsistent with the rest.

* More modules need to be required everywhere. If module A provides a
procedure that accepts a type from module B, all modules using that
procedure must also require the module B to know the type. In normal
Racket it does not matter as long as you just pass the opaque data along.

* Syntax macros are extra hard. As I use some syntax trickery to convert
semi-regular code to "futurized" one, I basically gave up and just ran
everything single-threaded. The main issue is passing type information
from the module that uses the macro to the macro and matching it on both
sides. Also the macro must split the type annotation from argument names
in the syntax pattern when it defines new procedures - I did some ugly
hacks to get through it but in the end I just refrained from using them
when possible (except for the unsafe-struct macro, of course).

If anyone actively working on TR reads this, I'd be more than happy to
discuss my experience and share the code (although it is really ugly as
I really only intended to prove the unsafe structs are used safely).
Next Saturday would be a good time to 

[racket-users] Re: idea for enlighting Scheme syntax

2021-01-02 Thread damien...@gmail.com
to be complete , the form {varriable ← value} with curly brackets used in 
simple assignation works too in LET-ARROW*:
scheme@(guile-user)>  (let-arrow* ({x ← 1}
{y ← {x + 1}})
x
y)
$2 = 2

but the simpliest form works also:
(let-arrow* (x ← 1
 y ← {x + 1})
x
y)



On Saturday, January 2, 2021 at 12:04:35 PM UTC+1 damien...@gmail.com wrote:

> hello,
>
> i made a few macros for scheme syntax improvments.
> It uses infix Curly expressions syntax described in SRFI 105 
> and could be combined to use with SRFI 47 in multi dimensional arrays.
>
> Curly expressions allows out of the box syntax more mathematicals like:
>
> {c > t} instead of (> c t)
>
> my macros allows more:
>
> assignations of variables, examples:
> (define x '())
>  {x ← 2}
> it returns 2,the value of x
> {7 → x} ;; not my own idea suggested by my daughter studying python 
> because in math we can write 7 = x in an equation but not in python :-)
>
> {cpt <- 0}
> {cpt <- {cpt + 1}}
>
> but this would be not complete without a way to have vector and array 
> access and assignation too:
> (define T (make-vector 5))
> (vector-set! T 3 7)
> {T[3]}
> returns 7, the value of T[3]
>
> assignation of vector:
> {T[3] <- 7}
>
> works too with multidimensional arrays:
> (define a (make-array 999 '(1 2) '(3 4)))
> {a[2 4]}
> returns 999
>
> harder to code, affectaion between arrays and vectors :
> {T[3] <- T[4]}
> ;; assign and returns the value of T[3]
> '{T[3] <- T[4]}  will return :  (<- ($bracket-apply$ T 3) ($bracket-apply$ 
> T 4))
>
> {a[1 3] <- a[2 4]}
> {a[2 4] ← 7}
> {1 → a[2 4]}
>
> those works at toplevel of REPL and in statements or block of code or body 
> of lambda, now works too with LET end LET* and LETREC in the affectation 
> body and in the statements part:
>
> first a simplified LET named LOCAL as in CLOJURE Lisp that use less 
> brackets:
> (local [ x 1
> y (+ x 1)
> z (+ 2 y) ]
>  z 
>  y)
>
> returns 2
>
> new special forms :
>
>  (let-arrow* (x ← 1
>   y ← {x + 1})
>  y)
>
> returns 2
>
> (let-arrow* [ x 1 
>   y (+ x 1) 
>   z (+ 2 y) ]
>   z y)
>
> the same works with LETREC:
>
> (letrec-arrow* [ fact ← (lambda (n)
>(if  {n = 1}
> 1
> {n * (fact {n - 1})}))
>]
> (fact 5))
>
> ;; = 120
>
>
>
> this works with Guile Scheme, the implementation of macros needs only R5RS 
> scheme and the SRFI 105, i hope it could works a day in Racket and others 
> Scheme implementation .
>
> example in real code:
> https://github.com/damien-mattei/scheme4algo/blob/master/SssRec.scm#L245
>
> the code can be found here:
> for LET-ARROW* and LETREC-ARROW*: 
> https://github.com/damien-mattei/library-FunctProg/blob/master/let.scm#L85
>
> Bracket-apply overload and arrows assignations :
>
> https://github.com/damien-mattei/library-FunctProg/blob/master/array.scm#L131
>
> https://github.com/damien-mattei/library-FunctProg/blob/master/array.scm#L101
>
>
> I wrote a little outdated page blog about that:
> http://balistra.canalblog.com/archives/2020/12/01/38692230.html
>
> Racket use different schema for infix notation, one with ($ "string infix 
> expression") and another with . (dot) such as (x . + . 1) ,they are not 
> usable ,the latter . dot notation is a real nightmare. The best way would 
> be to overload the READER of REPL as described in SRFI 105 Curly 
> expressions.
>
> Damien
>
>
>
>

-- 
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/f5c24ed0-6981-46d1-b712-481ce728a8e8n%40googlegroups.com.


[racket-users] idea for enlighting Scheme syntax

2021-01-02 Thread damien...@gmail.com
hello,

i made a few macros for scheme syntax improvments.
It uses infix Curly expressions syntax described in SRFI 105 
and could be combined to use with SRFI 47 in multi dimensional arrays.

Curly expressions allows out of the box syntax more mathematicals like:

{c > t} instead of (> c t)

my macros allows more:

assignations of variables, examples:
(define x '())
 {x ← 2}
it returns 2,the value of x
{7 → x} ;; not my own idea suggested by my daughter studying python because 
in math we can write 7 = x in an equation but not in python :-)

{cpt <- 0}
{cpt <- {cpt + 1}}

but this would be not complete without a way to have vector and array 
access and assignation too:
(define T (make-vector 5))
(vector-set! T 3 7)
{T[3]}
returns 7, the value of T[3]

assignation of vector:
{T[3] <- 7}

works too with multidimensional arrays:
(define a (make-array 999 '(1 2) '(3 4)))
{a[2 4]}
returns 999

harder to code, affectaion between arrays and vectors :
{T[3] <- T[4]}
;; assign and returns the value of T[3]
'{T[3] <- T[4]}  will return :  (<- ($bracket-apply$ T 3) ($bracket-apply$ 
T 4))

{a[1 3] <- a[2 4]}
{a[2 4] ← 7}
{1 → a[2 4]}

those works at toplevel of REPL and in statements or block of code or body 
of lambda, now works too with LET end LET* and LETREC in the affectation 
body and in the statements part:

first a simplified LET named LOCAL as in CLOJURE Lisp that use less 
brackets:
(local [ x 1
y (+ x 1)
z (+ 2 y) ]
 z 
 y)

returns 2

new special forms :

 (let-arrow* (x ← 1
  y ← {x + 1})
 y)

returns 2

(let-arrow* [ x 1 
  y (+ x 1) 
  z (+ 2 y) ]
  z y)

the same works with LETREC:

(letrec-arrow* [ fact ← (lambda (n)
   (if  {n = 1}
1
{n * (fact {n - 1})}))
   ]
(fact 5))

;; = 120



this works with Guile Scheme, the implementation of macros needs only R5RS 
scheme and the SRFI 105, i hope it could works a day in Racket and others 
Scheme implementation .

example in real code:
https://github.com/damien-mattei/scheme4algo/blob/master/SssRec.scm#L245

the code can be found here:
for LET-ARROW* and LETREC-ARROW*: 
https://github.com/damien-mattei/library-FunctProg/blob/master/let.scm#L85

Bracket-apply overload and arrows assignations :
https://github.com/damien-mattei/library-FunctProg/blob/master/array.scm#L131
https://github.com/damien-mattei/library-FunctProg/blob/master/array.scm#L101


I wrote a little outdated page blog about that:
http://balistra.canalblog.com/archives/2020/12/01/38692230.html

Racket use different schema for infix notation, one with ($ "string infix 
expression") and another with . (dot) such as (x . + . 1) ,they are not 
usable ,the latter . dot notation is a real nightmare. The best way would 
be to overload the READER of REPL as described in SRFI 105 Curly 
expressions.

Damien



-- 
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/57244a1b-7503-4b63-b5e5-ac7294bcf2bcn%40googlegroups.com.