Re: [racket-users] hacking falsiness

[Matthias Felleisen]

What Is the Name of This Book?
https://www.amazon.com/What-Name-This-Book-Recreational/dp/0486481980 
   



> On Jul 1, 2017, at 8:27 PM, Matthew Butterick  wrote:
> 
> 
>> On Jul 1, 2017, at 3:43 PM, Matthew Flatt > > wrote:
>> 
>> You're right that there's nothing like `#%boolean`. Beware that
>> adjusting all the `if`s in a fully expanded module won't help if the
>> expanded code call calls `filter`, `not`, or any other function from a
>> different module that expects a boolean. That's hitting the limits of
>> how well we know to make different kinds of languages interoperate.
> 
> Perfect — now I have a topic AND title for my PhD dissertation:
> 
> "My Thesis Is Not True"
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

Re: [racket-users] hacking falsiness

[Matthew Butterick]

> On Jul 1, 2017, at 3:43 PM, Matthew Flatt  wrote:
> 
> You're right that there's nothing like `#%boolean`. Beware that
> adjusting all the `if`s in a fully expanded module won't help if the
> expanded code call calls `filter`, `not`, or any other function from a
> different module that expects a boolean. That's hitting the limits of
> how well we know to make different kinds of languages interoperate.

Perfect — now I have a topic AND title for my PhD dissertation:

"My Thesis Is Not True"

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

Re: [racket-users] hacking falsiness

[Matthias Felleisen]

Boolean does play a special role. See the teaching languages for the reverse of 
the problem (easier). 



> On Jul 1, 2017, at 6:43 PM, Matthew Flatt  wrote:
> 
> At Sat, 1 Jul 2017 14:06:04 -0700, Matthew Butterick wrote:
>> Good idea, but can I introduce a new macro (which naturally needs expansion) 
>> into a fully-expanded module (which does not)?
> 
> Yes, you can expand, add non-core forms, and let the result get
> expanded again.
> 
> You're right that there's nothing like `#%boolean`. Beware that
> adjusting all the `if`s in a fully expanded module won't help if the
> expanded code call calls `filter`, `not`, or any other function from a
> different module that expects a boolean. That's hitting the limits of
> how well we know to make different kinds of languages interoperate.
> 
> At Sat, 1 Jul 2017 14:53:44 -0700, Matthew Butterick wrote:
>> 
>>> On Jul 1, 2017, at 2:24 PM, Deren Dohoda  wrote:
>>> 
>>> If your #lang has Greg's "if" then any module written in that #lang will 
>>> use 
>> that "if". 
>> 
>> IIUC Greg is suggesting something different than the usual shadow-and-export 
>> fandango that a module language ordinarily uses. 
>> 
>> He is suggesting that, because all conditional forms expand into some 
>> version 
>> of #%kernel `if` (again IIUC) that we change what values this #%kernel `if` 
>> accepts as true (thereby affecting all higher-level conditional forms) by 
>> operating on the fully expanded syntax object (because that's where the 
>> #%kernel `if` is totally exposed, IIUC #3).
>> 
>> IOW, #%kernel `if` is the closest thing to a single point of control for all 
>> Boolean behavior. 
>> 
>> Of course you could use shadow-and-export to change all the conditionals 
>> individually — `if` `and` `or` `cond` ... — but this would a drag, and 
>> error-prone anyhow.
>> 
>> 
>>> So if I understand, your concern is that someone calls a procedure which 
>>> has 
>> some conditional behavior but that procedure, being written in another 
>> module 
>> entirely, won't use Greg's "if". That is, your #lang will provide all sorts 
>> of 
>> procedures from racket/base and other modules, and those won't see Greg's 
>> "if". Is that correct?
>> 
>> Not quite. I just want code written within modules that use my DSL to have a 
>> more expansive notion of falsiness. (What happens in "another module 
>> entirely" 
>> is none of my business. Though, in the same way a module might provide 
>> special-effects flavors of `#%datum` or `#%app` or `#%top`, we could imagine 
>> modules that provide special Boolean behavior)
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [racket-users] hacking falsiness

[Matthew Flatt]

At Sat, 1 Jul 2017 14:06:04 -0700, Matthew Butterick wrote:
> Good idea, but can I introduce a new macro (which naturally needs expansion) 
> into a fully-expanded module (which does not)?

Yes, you can expand, add non-core forms, and let the result get
expanded again.

You're right that there's nothing like `#%boolean`. Beware that
adjusting all the `if`s in a fully expanded module won't help if the
expanded code call calls `filter`, `not`, or any other function from a
different module that expects a boolean. That's hitting the limits of
how well we know to make different kinds of languages interoperate.

At Sat, 1 Jul 2017 14:53:44 -0700, Matthew Butterick wrote:
> 
> > On Jul 1, 2017, at 2:24 PM, Deren Dohoda  wrote:
> > 
> > If your #lang has Greg's "if" then any module written in that #lang will 
> > use 
> that "if". 
> 
> IIUC Greg is suggesting something different than the usual shadow-and-export 
> fandango that a module language ordinarily uses. 
> 
> He is suggesting that, because all conditional forms expand into some version 
> of #%kernel `if` (again IIUC) that we change what values this #%kernel `if` 
> accepts as true (thereby affecting all higher-level conditional forms) by 
> operating on the fully expanded syntax object (because that's where the 
> #%kernel `if` is totally exposed, IIUC #3).
> 
> IOW, #%kernel `if` is the closest thing to a single point of control for all 
> Boolean behavior. 
> 
> Of course you could use shadow-and-export to change all the conditionals 
> individually — `if` `and` `or` `cond` ... — but this would a drag, and 
> error-prone anyhow.
> 
> 
> > So if I understand, your concern is that someone calls a procedure which 
> > has 
> some conditional behavior but that procedure, being written in another module 
> entirely, won't use Greg's "if". That is, your #lang will provide all sorts 
> of 
> procedures from racket/base and other modules, and those won't see Greg's 
> "if". Is that correct?
> 
> Not quite. I just want code written within modules that use my DSL to have a 
> more expansive notion of falsiness. (What happens in "another module 
> entirely" 
> is none of my business. Though, in the same way a module might provide 
> special-effects flavors of `#%datum` or `#%app` or `#%top`, we could imagine 
> modules that provide special Boolean behavior)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [racket-users] hacking falsiness

[Matthew Butterick]

> On Jul 1, 2017, at 2:24 PM, Deren Dohoda  wrote:
> 
> If your #lang has Greg's "if" then any module written in that #lang will use 
> that "if". 

IIUC Greg is suggesting something different than the usual shadow-and-export 
fandango that a module language ordinarily uses. 

He is suggesting that, because all conditional forms expand into some version 
of #%kernel `if` (again IIUC) that we change what values this #%kernel `if` 
accepts as true (thereby affecting all higher-level conditional forms) by 
operating on the fully expanded syntax object (because that's where the 
#%kernel `if` is totally exposed, IIUC #3).

IOW, #%kernel `if` is the closest thing to a single point of control for all 
Boolean behavior. 

Of course you could use shadow-and-export to change all the conditionals 
individually — `if` `and` `or` `cond` ... — but this would a drag, and 
error-prone anyhow.


> So if I understand, your concern is that someone calls a procedure which has 
> some conditional behavior but that procedure, being written in another module 
> entirely, won't use Greg's "if". That is, your #lang will provide all sorts 
> of procedures from racket/base and other modules, and those won't see Greg's 
> "if". Is that correct?

Not quite. I just want code written within modules that use my DSL to have a 
more expansive notion of falsiness. (What happens in "another module entirely" 
is none of my business. Though, in the same way a module might provide 
special-effects flavors of `#%datum` or `#%app` or `#%top`, we could imagine 
modules that provide special Boolean behavior)

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

Re: [racket-users] hacking falsiness

[Deren Dohoda]

Matthew,

If your #lang has Greg's "if" then any module written in that #lang will
use that "if". So if I understand, your concern is that someone calls a
procedure which has some conditional behavior but that procedure, being
written in another module entirely, won't use Greg's "if". That is, your
#lang will provide all sorts of procedures from racket/base and other
modules, and those won't see Greg's "if". Is that correct?

On Sat, Jul 1, 2017 at 5:06 PM, Matthew Butterick  wrote:

> Good idea, but can I introduce a new macro (which naturally needs
> expansion) into a fully-expanded module (which does not)?
>
> IOW, it feels like you'd need to mangle #%kernel `if` before expansion, so
> that all the higher level expansions landed on the new mangled form.
>
> Mangling #%datum won't quite work, because it doesn't know whether the
> datum is being evaluated in a Boolean context.
>
> Feels like I'm wishing for a `#%boolean` hook that wraps a value that's
> about to be evaluated for its Boolean result.
>
> > On Jul 1, 2017, at 10:29 AM, Greg Hendershott 
> wrote:
> >
> > In fully-expanded programs, do all of the desired conditional forms
> > reduce to #%kernel `if`?
> >
> > If so, could your #%module-begin walk the fully-expanded module syntax
> > and replace all the #%kernel `if`s with something like (quick sketch):
> >
> > (require (rename-in racket/base [if r:if]))
> > (define-syntax-rule (if -e -t -f)
> >  (let ([e -e]
> >[f -f])
> >(r:if (eq? e #f)
> >  f
> >  (r:if (eq? e 0)
> >f
> >(r:if (eq? e null)
> >  f
> >  -t)
> >
> > ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [racket-users] hacking falsiness

[Matthew Butterick]

Good idea, but can I introduce a new macro (which naturally needs expansion) 
into a fully-expanded module (which does not)?

IOW, it feels like you'd need to mangle #%kernel `if` before expansion, so that 
all the higher level expansions landed on the new mangled form. 

Mangling #%datum won't quite work, because it doesn't know whether the datum is 
being evaluated in a Boolean context. 

Feels like I'm wishing for a `#%boolean` hook that wraps a value that's about 
to be evaluated for its Boolean result. 

> On Jul 1, 2017, at 10:29 AM, Greg Hendershott  
> wrote:
> 
> In fully-expanded programs, do all of the desired conditional forms
> reduce to #%kernel `if`?
> 
> If so, could your #%module-begin walk the fully-expanded module syntax
> and replace all the #%kernel `if`s with something like (quick sketch):
> 
> (require (rename-in racket/base [if r:if]))
> (define-syntax-rule (if -e -t -f)
>  (let ([e -e]
>[f -f])
>(r:if (eq? e #f)
>  f
>  (r:if (eq? e 0)
>f
>(r:if (eq? e null)
>  f
>  -t)
> 
> ?

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

Re: [racket-users] hacking falsiness

[Greg Hendershott]

In fully-expanded programs, do all of the desired conditional forms
reduce to #%kernel `if`?

If so, could your #%module-begin walk the fully-expanded module syntax
and replace all the #%kernel `if`s with something like (quick sketch):

(require (rename-in racket/base [if r:if]))
(define-syntax-rule (if -e -t -f)
  (let ([e -e]
[f -f])
(r:if (eq? e #f)
  f
  (r:if (eq? e 0)
f
(r:if (eq? e null)
  f
  -t)

?

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

[racket-users] hacking falsiness

[Matthew Butterick]

Suppose I'm making a DSL where #f, 0, and null all count as false values. 

What is the most efficient way to do this? IOW, is there a deep-and-simple way 
of globally affecting the Boolean tower (meaning, automatically changing all 
conditional forms)? Or does one have to build a new tower from the ground up?

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