A value for "nothing"

A value for "nothing"

[HiPhish]

Hello Schemers,

I am writing an implementation of MessagePack [1] for Guile and a part of the 
spec is the presence of a "nil" data type. What would be a good value to 
express "nothing" in Guile? I cannot use '() because that would be 
indistinguishable from the empty list, so I thought that the return value of a 
function that returns nothing would be a good fit. The function `display` for 
example returns an `#<unspecified>` value, but the only way of producing it 
without side effects so for is the value of `(if #f #f)`. Is there a better 
way?

In Racket there is the `(void)` [2] procedure which returns a `#<void>` 
object, so that's what I am using there [3][4]. Any suggestions for Guile?

[1] https://msgpack.org/
[2] http://docs.racket-lang.org/reference/void.html?q=void
[3] https://gitlab.com/HiPhish/MsgPack.rkt/blob/master/msgpack/unpack.rkt#L47
[4] https://gitlab.com/HiPhish/MsgPack.rkt/blob/master/msgpack/pack.rkt#L35

Re: A value for "nothing"

[Thomas Morley]

2018-08-26 12:13 GMT+02:00 HiPhish <hiphish@posteo.de>:
> Hello Schemers,
>
> I am writing an implementation of MessagePack [1] for Guile and a part of the
> spec is the presence of a "nil" data type. What would be a good value to
> express "nothing" in Guile? I cannot use '() because that would be
> indistinguishable from the empty list, so I thought that the return value of a
> function that returns nothing would be a good fit. The function `display` for
> example returns an `#<unspecified>` value, but the only way of producing it
> without side effects so for is the value of `(if #f #f)`. Is there a better
> way?

Well, actually that's how the value of *unspecified* is defined.

From boot9.scm:

;;; {The Unspecified Value}
;;;
;;; Currently Guile represents unspecified values via one particular value,
;;; which may be obtained by evaluating (if #f #f). It would be nice in the
;;; future if we could replace this with a return of 0 values, though.
;;;

(define-syntax *unspecified*
  (identifier-syntax (if #f #f)))

(define (unspecified? v) (eq? v *unspecified*))



Cheers,
  Harm

>
> In Racket there is the `(void)` [2] procedure which returns a `#<void>`
> object, so that's what I am using there [3][4]. Any suggestions for Guile?
>
> [1] https://msgpack.org/
> [2] http://docs.racket-lang.org/reference/void.html?q=void
> [3] https://gitlab.com/HiPhish/MsgPack.rkt/blob/master/msgpack/unpack.rkt#L47
> [4] https://gitlab.com/HiPhish/MsgPack.rkt/blob/master/msgpack/pack.rkt#L35
>
>
>

Re: A value for "nothing"

[Joshua Branson]

HiPhish <hiphish@posteo.de> writes:

> Hello Schemers,
>
>
> [1] https://msgpack.org/

Thanks for mentioning this!  I'm not sure how to answer your question,
but thanks for pointing out msgpack.  I hadn't realized that json could
be faster if it was encoded in binary.  That's awesome!

Re: A value for "nothing"

[John Cowan]

Well, you could use #nil, a Guile-specific unique object that is both falsy
(like #f) and answers #t to the null? predicate.  It is used to emulate
Common Lisp's and Elisp's nil.  But a more portable approach would be to
define a record type with no slots and make just one instance of it.

On Sun, Aug 26, 2018 at 10:09 AM HiPhish <hiphish@posteo.de> wrote:

> Hello Schemers,
>
> I am writing an implementation of MessagePack [1] for Guile and a part of
> the
> spec is the presence of a "nil" data type. What would be a good value to
> express "nothing" in Guile? I cannot use '() because that would be
> indistinguishable from the empty list, so I thought that the return value
> of a
> function that returns nothing would be a good fit. The function `display`
> for
> example returns an `#<unspecified>` value, but the only way of producing
> it
> without side effects so for is the value of `(if #f #f)`. Is there a
> better
> way?
>
> In Racket there is the `(void)` [2] procedure which returns a `#<void>`
> object, so that's what I am using there [3][4]. Any suggestions for Guile?
>
> [1] https://msgpack.org/
> [2] http://docs.racket-lang.org/reference/void.html?q=void
> [3]
> https://gitlab.com/HiPhish/MsgPack.rkt/blob/master/msgpack/unpack.rkt#L47
> [4]
> https://gitlab.com/HiPhish/MsgPack.rkt/blob/master/msgpack/pack.rkt#L35
>
>
>
>

Re: A value for "nothing"

[Mark H Weaver]

John Cowan <cowan@ccil.org> writes:

> Well, you could use #nil, a Guile-specific unique object that is both falsy
> (like #f) and answers #t to the null? predicate.  It is used to emulate
> Common Lisp's and Elisp's nil.

As I wrote earlier, I would avoid using #nil for anything outside of its
intended use case.

> But a more portable approach would be to define a record type with no
> slots and make just one instance of it.

If _all_ symbols must be distinguishable from the "nothing" object, then
John's suggestion is a fine solution.  To avoid unnecessary heap
allocation, you should indeed arrange to make only one instance of it,
as John said.

However, in most cases, symbols are precisely what's needed to represent
distinguished atomic objects such as this.

I looked at <https://en.wikipedia.org/wiki/MessagePack> and I don't see
why a symbol couldn't be used to represent MessagePack's 'nil'.

I hope that HiPhish is not planning to use symbols to represent
MessagePack strings.  That would be an abuse of symbols, IMO.  Symbols
are intended to represent atomic objects (i.e. objects containing no
internal structure) whose only essential operation is to compare them
for equality.

A practical problem with using symbols to represent strings is that
symbols need to be "interned", i.e. stored in a global hash table, to
ensure that any two symbols containing the same sequence of characters
are represented by the same object.  A consequence of this is that every
time a new symbol is encountered, it must be added to the global hash
table, which in turn must be protected by a mutex.  This would slow down
creation of MessagePack strings, especially if several threads are doing
it concurrently, to no good end that I can see.

       Mark

Re: A value for "nothing"

[John Cowan]

On Mon, Aug 27, 2018 at 12:54 AM Mark H Weaver <mhw@netris.org> wrote:


> However, in most cases, symbols are precisely what's needed to represent
> distinguished atomic objects such as this.
>

The problem with symbols in Scheme is that they are not namespaced, so
two different modules can use the same symbols in different ways.
Exported variable bindings can be managed with the module system.


> I hope that HiPhish is not planning to use symbols to represent
> MessagePack strings.
>

However, in formats like JSON where map keys are always strings,
it can save a lot of space to represent them as symbols, since
they are often repeated from one object to the next.  There is no such
limitation in MessagePack, although I bet strings are the most common
type of map keys.

-- 
John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Knowledge studies others / Wisdom is self-known;
Muscle masters brothers / Self-mastery is bone;
Content need never borrow / Ambition wanders blind;
Vitality cleaves to the marrow / Leaving death behind.    --Tao 33 (Bynner)

Re: A value for "nothing"

[Mark H Weaver]

John Cowan <cowan@ccil.org> writes:

> On Mon, Aug 27, 2018 at 12:54 AM Mark H Weaver <mhw@netris.org> wrote:
>  
>  However, in most cases, symbols are precisely what's needed to represent
>  distinguished atomic objects such as this.
>
> The problem with symbols in Scheme is that they are not namespaced, so
> two different modules can use the same symbols in different ways.
> Exported variable bindings can be managed with the module system.

Right, but this is only a problem if the same variable might contain
either a MessagePack or some other data type that uses the same symbol
to mean something different.  In other words, this is only a problem if
you need to be able to distinguish between a MessagePack and some other
data type.

However, given that a MessagePack can also be a boolean, integer, float,
string, etc, and that the plan is apparently to use the corresponding
native Scheme objects to represent these things (which I agree is a good
idea), it will already be infeasible to distinguish between a
MessagePack and anything else.

So, while I agree that this is something to keep in mind when using
symbols in Scheme, I think it's a moot point in this case.

On the other hand, one disadvantage with using record types is that they
cannot be written and then read back in with the standard Scheme reader.
If this is considered desirable, it might be a point in favor of using
symbols instead of records.

      Mark

Re: A value for "nothing"

[Mark H Weaver]

John Cowan <cowan@ccil.org> writes:
> However, in formats like JSON where map keys are always strings,
> it can save a lot of space to represent them as symbols, since
> they are often repeated from one object to the next.  There is no such
> limitation in MessagePack, although I bet strings are the most common
> type of map keys.

Agree that this is a point in favor of using symbols to represent
MessagePack strings.

       Mark

Re: A value for "nothing"

[Mark H Weaver]

Hi,

HiPhish <hiphish@posteo.de> writes:

> I am writing an implementation of MessagePack [1] for Guile and a part of the 
> spec is the presence of a "nil" data type. What would be a good value to 
> express "nothing" in Guile?

First of all, thank you very much for asking the question.  I often wish
that authors of Guile libraries would more often ask for design advice
here before committing to a particular API.

> I cannot use '() because that would be 
> indistinguishable from the empty list, so I thought that the return value of a 
> function that returns nothing would be a good fit.

"The return value of a function that returns nothing" is a
self-contradictory notion, if you think about it :)

> The function `display` for 
> example returns an `#<unspecified>` value, but the only way of producing it 
> without side effects so for is the value of `(if #f #f)`. Is there a better 
> way?

*unspecified* is identifier syntax for (if #f #f), i.e. it expands into
the latter.

However, I would strongly advise against writing code (or worse, APIs)
that depend on (if #f #f) or *unspecified* returning a particular
distinguished value.

Quoting R5RS:

  If the value of an expression is said to be "unspecified," then the
  expression must evaluate to some object without signalling an error,
  but the value depends on the implementation; this report explicitly
  does not say what value should be returned.

It's true that Guile historically has a special object distinct from all
other objects, which (if #f #f) and various other expressions return,
and which prints as "#<unspecified>".

However, the fact that some existing code out there might depend on the
existence of this distinguished object, and that certain expressions in
Guile return it, is historical baggage which carries non-zero costs as
we move to native code generation.

I would also argue that it carries a terrible conceptual cost, in that
it leads to confusion between the concept of a truly unspecified return
value (as in R5RS) and this distinguished value in Guile that is called
"the unspecified value", a non-sensical notion.

I would also avoid Guile's #nil.  That is a very special value, for one
purpose relating to Elisp compatibility, and ideally it should not be
used for anything else.

> In Racket there is the `(void)` [2] procedure which returns a `#<void>` 
> object, so that's what I am using there [3][4]. Any suggestions for Guile?

I would suggest using a symbol.  How about 'nil?

      Mark
 

Re: A value for "nothing"

[Matt Wette]

On 08/26/2018 01:07 PM, Mark H Weaver wrote:

> HiPhish <hiphish@posteo.de> writes:
>
>> I am writing an implementation of MessagePack [1] for Guile and a part of the
>> spec is the presence of a "nil" data type. What would be a good value to
>> express "nothing" in Guile?

> However, I would strongly advise against writing code (or worse, APIs)
> that depend on (if #f #f) or *unspecified* returning a particular
> distinguished value.

That tells me we should never use `(define x)'.

> I would also avoid Guile's #nil.  That is a very special value, for one
> purpose relating to Elisp compatibility, and ideally it should not be
> used for anything else.

#nil only appears in the manual in association with the elisp extension.
I'm guessing it only intended to only appear in Scheme programs as '(const #nil)
when writing tree-il.

Re: A value for "nothing"

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Aug 26, 2018 at 04:07:13PM -0400, Mark H Weaver wrote:

[...]

> It's true that Guile historically has a special object distinct from all
> other objects, which (if #f #f) and various other expressions return,
> and which prints as "#<unspecified>".
> 
> However, the fact that some existing code out there might depend on the
> existence of this distinguished object, and that certain expressions in
> Guile return it, is historical baggage which carries non-zero costs as
> we move to native code generation.
> 
> I would also argue that it carries a terrible conceptual cost, in that
> it leads to confusion between the concept of a truly unspecified return
> value (as in R5RS) and this distinguished value in Guile that is called
> "the unspecified value", a non-sensical notion.
> 
> I would also avoid Guile's #nil.  That is a very special value, for one
> purpose relating to Elisp compatibility, and ideally it should not be
> used for anything else.

I must admit that I'm... pretty confused about this very prescriptive
tone.

Sorry.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAluDsH8ACgkQBcgs9XrR2kZCMwCfQpgyL+cC38ZHKqhV0rAG02sq
+WIAnjXIVutY/p0Q3nrbZjfNuVzhcDgY
=/B5d
-----END PGP SIGNATURE-----

Re: A value for "nothing"

[Mark H Weaver]

<tomas@tuxteam.de> writes:

> On Sun, Aug 26, 2018 at 04:07:13PM -0400, Mark H Weaver wrote:
>
>> I would also avoid Guile's #nil.  That is a very special value, for one
>> purpose relating to Elisp compatibility, and ideally it should not be
>> used for anything else.
>
> I must admit that I'm... pretty confused about this very prescriptive
> tone.

You're right, I should have explained.  I'm overburdened at the moment.

For one thing, HiPhish has already indicated that his library will
support both Guile and Racket, so I conclude that he's at least somewhat
interested in portability to other Scheme implementations.

If he would like people to be able to write code that uses his library
and works on multiple Scheme implementations, then it will certainly be
an impediment to use a Racket-specific value for Nil on Racket, and a
Guile-specific value for Nil on Guile.  It would be much better to use a
portable Scheme data structure uniformly.

More generally, even for people only interested in supporting Guile, if
they would like their libraries to be usable from Elisp code on Guile,
which may become important some day if Guile-Emacs matures, then it's
problematic to use #nil for anything that needs to be distinguished from
'() or #f.

Alternatively, if Guile-Emacs dies and people give up on that project,
which is entirely possible, then we should probably deprecate #nil at
some point and eventually remove it.  Supporting #nil has costs, both in
performance and in the size of generated native code, when checking
whether an object is true (in every 'if' or 'cond') and when checking
for '().  That performance cost is insignificant in an interpreter or VM
implementation, but as we move to native code generation it may become
significant, as both of the aforementioned operations are quite
ubiquitous.

       Mark

Re: A value for "nothing"

[Mark H Weaver]

I wrote:
> If he would like people to be able to write code that uses his library
> and works on multiple Scheme implementations, then it will certainly be
> an impediment to use a Racket-specific value for Nil on Racket, and a
> Guile-specific value for Nil on Guile.  It would be much better to use a
> portable Scheme data structure uniformly.

One might object, and point out that since the library will presumably
include procedures to construct and test for nil, it shouldn't matter if
they are represented by different objects under the hood.

The problem is, if #nil is used, it's quite likely that some code built
on top of this library and developed using Guile will end up relying on
the fact that #nil is considered false, and that (null? #nil) returns
true.  That would lead to possibly subtle breakage when the same code is
then used on another implementation.

       Mark

Re: A value for "nothing"

[Matt Wette]

Is it reasonable to expect that if a value can be assigned to a variable
then a predicate exists to test for that value type?  So, if

   (define a (if #f #f))

does not signal an error then there should be a predicate to indicate the
value associated with a is unspecified?

If the define allowed in RnRS?  I don't believe there is a predicate to
test for this. (I could be wrong.)

Comments?

Matt

Re: A value for "nothing"

[Mark H Weaver]

Matt Wette <matt.wette@gmail.com> writes:

> Is it reasonable to expect that if a value can be assigned to a variable
> then a predicate exists to test for that value type?  So, if
>
>   (define a (if #f #f))
>
> does not signal an error then there should be a predicate to indicate the
> value associated with a is unspecified?
>
> If the define allowed in RnRS?  I don't believe there is a predicate to
> test for this. (I could be wrong.)

In RnRS, (define a (if #f #f)) is allowed and guaranteed to assign
*some* object to 'a' without signalling an error.  However, it's not
specified what object will be assigned.  It could be 2 or (foo bar) or
"the cow jumps over the moon".

So, in RnRS, there's no predicate that you could apply to 'a' and be
assured that the result will be #t on all conforming implementations.

Guile has always had a predicate 'unspecified?' since at least 1996, but
personally I would advise against relying on its continued existence in
the future.

Regarding your question whether it's reasonable to expect that every
object has an associated predicate to test for it, I don't know.  It's
an interesting question, but I wonder what would be the practical use of
such an expectation?

Given the fact that there are several mechanisms to add new types that
are distinct from all other types, and that we occasionally add new core
types to Guile that no previously extant predicate would answer #t for,
you certainly cannot rely on being able to write a 'cond' statement that
tests an arbitrary object using some set of predicates and be assured
that at least one of those predicates will answer #t.  You could write
such a 'cond' statement today with that property, but for a future
version of Guile you might find an object for which none of those
predicates returns #t.

     Regards,
       Mark

Re: A value for "nothing"

[John Cowan]

On Tue, Aug 28, 2018 at 3:01 AM Mark H Weaver <mhw@netris.org> wrote:


> In RnRS, (define a (if #f #f)) is allowed and guaranteed to assign
> *some* object to 'a' without signalling an error.


Actually, the phrase used is "the result is unspecified", which
unfortunately
is not defined in any RnRS.  Racket produces a syntax error in this
situation
at least in its default language.


> However, it's not
> specified what object will be assigned.  It could be 2 or (foo bar) or
> "the cow jumps over the moon".
>

In practice, it is #t, #f, (), or a unique unspecified object across all the
Schemes I have tested, most often the last.

-- 
John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
LEAR: Dost thou call me fool, boy?
FOOL: All thy other titles thou hast given away:
That thou wast born with.

Re: A value for "nothing"

[Mark H Weaver]

John Cowan <cowan@ccil.org> writes:

> On Tue, Aug 28, 2018 at 3:01 AM Mark H Weaver <mhw@netris.org> wrote:
>  
>  In RnRS, (define a (if #f #f)) is allowed and guaranteed to assign
>  *some* object to 'a' without signalling an error.  
>
> Actually, the phrase used is "the result is unspecified", which unfortunately
> is not defined in any RnRS.

That's the phrase used in R7RS-small, which fails to define it, as you
noted, but that shortcoming is limited to R7RS.

In R6RS, section 11.4.3 (Conditionals) provides this example:

  (if #f #f) ===> unspecified

whose meaning is defined in section 6.6 (Evaluation examples), which
states:

  Moreover, the "===>" symbol is also used to explicitly say that the
  value of an expression is unspecified.  For example:

    (eqv? "" "") ===> unspecified

I take the use of the singular form of "value" here to imply that it
returns only one value.

R5RS is even more clear.  It states "If <test> yields a false value and
no <alternate> is specified, then the result of the expression is
unspecified."

Section 1.3.2 of R5RS makes it crystal clear what that means:

  If the value of an expression is said to be "unspecified," then the
  expression must evaluate to some object without signalling an error,
  but the value depends on the implementation; this report explicitly
  does not say what value should be returned.

> Racket produces a syntax error in this situation at least in its
> default language.

Racket has diverged from Scheme quite a bit, to the point that they
don't even call the language "Scheme" anymore, but rather "Racket".

       Mark

Re: A value for "nothing"

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> John Cowan <cowan@ccil.org> writes:
>
>> On Tue, Aug 28, 2018 at 3:01 AM Mark H Weaver <mhw@netris.org> wrote:
>>  
>>  In RnRS, (define a (if #f #f)) is allowed and guaranteed to assign
>>  *some* object to 'a' without signalling an error.  
>>
>> Actually, the phrase used is "the result is unspecified", which unfortunately
>> is not defined in any RnRS.
>
> That's the phrase used in R7RS-small, which fails to define it, as you
> noted, but that shortcoming is limited to R7RS.

Actually, the behavior _is_ clearly defined, in the formal denotational
semantics in both R5RS and R7RS.  If you learn how to read those, you'll
see that there's no question that (if #f #f) is guaranteed to return
exactly one unspecified value.

         Mark

Re: A value for "nothing"

[John Cowan]

On Tue, Aug 28, 2018 at 11:40 AM Mark H Weaver <mhw@netris.org> wrote:


> That's the phrase used in R7RS-small, which fails to define it, as you
> noted, but that shortcoming is limited to R7RS.
>

The relevant sentences in R5RS and R7RS are identical:  " If <test> yields
a false value and no <alternate> is specified, then the result of the
expression is unspecified."  Likewise, the paragraph from 1.3.2 you quote
below is identical in both standards.  So either they both define it or
they both don't.

In R6RS, section 11.4.3 (Conditionals) provides this example:
>

Unlike Wil Clinger, and apparently you, I don't believe that examples in
specs are normative.  But setting that aside for the moment:


> I take the use of the singular form of "value" here to imply that it
> returns only one value.
>

In R6RS 11.13, vector-set! is said to return unspecified values (note
plural), but in the examples appears "⇒ unspecified", showing that this
notation can be used where multiple unspecified values (or zero values) are
allowed.

In practice, I know of no Scheme implementation that returns other than one
value in any of these "unspecified values" situations, which IMO is a Good
Thing.

-- 
John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
With techies, I've generally found
If your arguments lose the first round
Make it rhyme, make it scan / Then you generally can
Make the same stupid point seem profound!           --Jonathan Robie

Re: A value for "nothing"

[Mark H Weaver]

John Cowan <cowan@ccil.org> writes:

> On Tue, Aug 28, 2018 at 11:40 AM Mark H Weaver <mhw@netris.org> wrote:
>  
>  That's the phrase used in R7RS-small, which fails to define it, as you
>  noted, but that shortcoming is limited to R7RS.
>
> The relevant sentences in R5RS and R7RS are identical: " If <test>
> yields a false value and no <alternate> is specified, then the result
> of the expression is unspecified."  Likewise, the paragraph from 1.3.2
> you quote below is identical in both standards.  So either they both
> define it or they both don't.
>
>  In R6RS, section 11.4.3 (Conditionals) provides this example:
>
> Unlike Wil Clinger, and apparently you, I don't believe that examples
> in specs are normative.

Alright, well, the formal denotational semantics makes it 100%
unambiguous, as I noted in my previous email.

       Mark

Re: A value for "nothing"

[Mark H Weaver]

Hi John,

John Cowan <cowan@ccil.org> writes:

> On Tue, Aug 28, 2018 at 11:40 AM Mark H Weaver <mhw@netris.org> wrote:
>  
>  That's the phrase used in R7RS-small, which fails to define it, as you
>  noted, but that shortcoming is limited to R7RS.
>
> The relevant sentences in R5RS and R7RS are identical: " If <test>
> yields a false value and no <alternate> is specified, then the result
> of the expression is unspecified."  Likewise, the paragraph from 1.3.2
> you quote below is identical in both standards.  So either they both
> define it or they both don't.

Good point, you're absolutely right about that.  I confess that I didn't
bother to check R7RS carefully, because I simply assumed that you had
good knowledge of it.  I only looked carefully at R5RS and R6RS, but I
guess we came to different conclusions from the same text.

>  In R6RS, section 11.4.3 (Conditionals) provides this example:
>
> Unlike Wil Clinger, and apparently you, I don't believe that examples
> in specs are normative.  But setting that aside for the moment:
>  
>  I take the use of the singular form of "value" here to imply that it
>  returns only one value.
>
> In R6RS 11.13, vector-set! is said to return unspecified values (note
> plural), but in the examples appears "⇒ unspecified", showing that
> this notation can be used where multiple unspecified values (or zero
> values) are allowed.

This is also a good point.  This looks like a mistake to me in R6RS.
Someone should probably notify them.

Anyway, these ambiguities in the informal descriptions underline the
importance of formal semantics.  Thankfully, the core constructs are
unambiguously described by them in the standards, including 'if'.

Thank you for your tireless efforts to promote Scheme standardization,
and also for helping me break through stone walls that were placed in my
way during the R7RS-small process.  I'm grateful for your work.

       Mark

Re: A value for "nothing"

[Hans Åberg]

> On 27 Aug 2018, at 22:12, Mark H Weaver <mhw@netris.org> wrote:
> 
> More generally, even for people only interested in supporting Guile, if
> they would like their libraries to be usable from Elisp code on Guile,
> which may become important some day if Guile-Emacs matures, then it's
> problematic to use #nil for anything that needs to be distinguished from
> '() or #f.

Maybe you need an addition: an empty value.

Re: A value for "nothing"

[Panicz Maciej Godek]

niedz., 26 sie 2018 o 16:09 HiPhish <hiphish@posteo.de> napisał(a):

> Hello Schemers,
>
> I am writing an implementation of MessagePack [1] for Guile and a part of
> the
> spec is the presence of a "nil" data type. What would be a good value to
> express "nothing" in Guile? I cannot use '() because that would be
> indistinguishable from the empty list, so I thought that the return value
> of a
> function that returns nothing would be a good fit. The function `display`
> for
> example returns an `#<unspecified>` value, but the only way of producing
> it
> without side effects so for is the value of `(if #f #f)`. Is there a
> better
> way?
>
>
In my experience, if #f doesn't make sense as a legal value, then using #f
is probably the idiomatic Scheme way to go.
It composes with SRFI-2's and-let* in a way similar to Haskell's Nothing
within the "do" notation.
I did find it useful when I was implementing a pattern matching facility,
where I could distinguish between an empty list of (successful) bindings
and a failed match.
But I think you would need to tell us more about the library: where do the
values come from and what do they represent. What would this "nil" data
type be supposed to stand for?

Re: A value for "nothing"

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Aug 27, 2018 at 02:17:06AM +0200, Panicz Maciej Godek wrote:
> niedz., 26 sie 2018 o 16:09 HiPhish <hiphish@posteo.de> napisał(a):
> 
> > Hello Schemers,
> >
> > I am writing an implementation of MessagePack [1] for Guile and a part of
> > the
> > spec is the presence of a "nil" data type. What would be a good value to
> > express "nothing" in Guile? I cannot use '() because that would be
> > indistinguishable from the empty list, so I thought that the return value
> > of a
> > function that returns nothing would be a good fit. The function `display`
> > for
> > example returns an `#<unspecified>` value, but the only way of producing
> > it
> > without side effects so for is the value of `(if #f #f)`. Is there a
> > better
> > way?
> >
> >
> In my experience, if #f doesn't make sense as a legal value, then using #f
> is probably the idiomatic Scheme way to go.

[...]

In this case, as msgpack has explicit true and false values, those seem
the "natural" correspondents of Scheme's #t and #f.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAluDsCQACgkQBcgs9XrR2kYI2QCeIL2joDmoLFb/8ckMDAGy1Ebd
0KQAn0k/6r4ZL9ZynRrjJ/xYJuE9BxyK
=+z4g
-----END PGP SIGNATURE-----

Re: A value for "nothing"

[Panicz Maciej Godek]

pon., 27 sie 2018 o 10:17 <tomas@tuxteam.de> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, Aug 27, 2018 at 02:17:06AM +0200, Panicz Maciej Godek wrote:
> > niedz., 26 sie 2018 o 16:09 HiPhish <hiphish@posteo.de> napisał(a):
> >
> > > Hello Schemers,
> > >
> > > I am writing an implementation of MessagePack [1] for Guile and a part
> of
> > > the
> > > spec is the presence of a "nil" data type. What would be a good value
> to
> > > express "nothing" in Guile? I cannot use '() because that would be
> > > indistinguishable from the empty list, so I thought that the return
> value
> > > of a
> > > function that returns nothing would be a good fit. The function
> `display`
> > > for
> > > example returns an `#<unspecified>` value, but the only way of
> producing
> > > it
> > > without side effects so for is the value of `(if #f #f)`. Is there a
> > > better
> > > way?
> > >
> > >
> > In my experience, if #f doesn't make sense as a legal value, then using
> #f
> > is probably the idiomatic Scheme way to go.
>
> [...]
>
> In this case, as msgpack has explicit true and false values, those seem
> the "natural" correspondents of Scheme's #t and #f.
>

If that's the case, then perhaps actually returning no value (as in the
(values) form with no arguments) is the way to go?

Re: A value for "nothing"

[HiPhish]

On Montag, 27. August 2018 02:17:06 CEST you wrote:
> In my experience, if #f doesn't make sense as a legal value, then using #f
> is probably the idiomatic Scheme way to go.
> It composes with SRFI-2's and-let* in a way similar to Haskell's Nothing
> within the "do" notation.
> I did find it useful when I was implementing a pattern matching facility,
> where I could distinguish between an empty list of (successful) bindings
> and a failed match.
> But I think you would need to tell us more about the library: where do the
> values come from and what do they represent. What would this "nil" data
> type be supposed to stand for?

I literally don't know where the values will come from, that's the thing. 
MessagePack is a data serialization format: a process has some in-memory 
object, turns it into bytes and later reads those bytes to generate an in-
memory object. The bytes could come from an entirely different process in a 
language which distinguishes between "nothing", "falsely" and "empty list". If 
you use MessagePack for a remote procedure call and on the other end you 
*must* be able to distinguish between those things, then you also *must* be 
able to distinguish them on Guile's end as well.

Re: A value for "nothing"

[HiPhish]

Yes, this sounds like the best solution so far.

On Sonntag, 26. August 2018 23:07:26 CEST you wrote:
> The eq? predicate is able to distinguish the three.  But I think using a
> singleton record is best:
> 
> (define-record-type (<nil> nil? make-nil))
> (define nil (make-nil))
> 
> and thene export njil and nil? but not <i>ni> or make-nil.

Re: A value for "nothing"

[HiPhish]

I think I understand: it just so happens that `(if #f #f)` evaluates to 
`#<unspecified>`, but it would still be valid if it evaluated to 5 or 
"roflcopter".

> "The return value of a function that returns nothing" is a
> self-contradictory notion, if you think about it :)
I was under the impression that in Lisp any S-expression evaluates to 
*something*, even if that something is some junk value or "nothing".
 
> I would suggest using a symbol.  How about 'nil?
I was considering the possibility of serialising symbols as strings, but then 
'nil would be indistinguishable from the string "nil". The more I think about, 
the more a singleton instance of a custom record makes sense.

Re: A value for "nothing"

[Ludovic Courtès]

Hi,

I would suggesting returning zero values, using:

  (values)

That way, if a caller wrongfully attempts to get at the return value of
that procedure, it’ll get an error.

Fibers does that in several places, and I think it’s a good convention
as it conveys exactly what you want.

Ludo’.

Re: A value for "nothing"

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> I would suggesting returning zero values, using:
>
>   (values)
>
> That way, if a caller wrongfully attempts to get at the return value of
> that procedure, it’ll get an error.
>
> Fibers does that in several places, and I think it’s a good convention
> as it conveys exactly what you want.

You cannot store (values) in a variable or data structure, so it
wouldn't work here.

The issue under discussion is how to represent MessagePack's "nil",
which is one of the possible values that a MessagePack can have,
alongside booleans, integers, floats, strings, arrays, etc.

MessagePack is similar to JSON, so the question we're discussing is
analogous to the question of how to represent JSON's "null" in Scheme.

      Mark

Re: A value for "nothing"

[Ludovic Courtès]

Hello,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> I would suggesting returning zero values, using:
>>
>>   (values)
>>
>> That way, if a caller wrongfully attempts to get at the return value of
>> that procedure, it’ll get an error.
>>
>> Fibers does that in several places, and I think it’s a good convention
>> as it conveys exactly what you want.
>
> You cannot store (values) in a variable or data structure, so it
> wouldn't work here.
>
> The issue under discussion is how to represent MessagePack's "nil",
> which is one of the possible values that a MessagePack can have,
> alongside booleans, integers, floats, strings, arrays, etc.

Oops, sorry for the off-topic reply!

In this context, my preference would be for a singleton type:

  (define-record-type <nothing>
    (nothing)
    nothing?)

Ludo’.

Re: A value for "nothing"

[HiPhish]

The main advantage of JSON is that it is human-readable. This is great if you 
want to save the data on disc and be able to get it without needing special 
software, or if you want to write it out by hand but be able to parse it by a 
computer. I actually had done that, I maintained a number of records by hand 
and use a small script to splice the data in a modified form into a LaTeX 
document.

However, being text-based becomes a liability when there is no need for human 
readability. For instance, if you want to send data between processes there 
will never be a human who will eyeball it, size and parsing efficiency are 
much more important. JSON is non-trivial to parse.

I am writing this implementation of MessagePack because I want to be able to 
write a Neovim client for Guile. This will effectively allow writing Neovim 
plugins in Guile: Neovim launches an external Guile process and the two 
processes communicate via RPC using MessagePack as the protocol. This way 
Neovim can be retrofitted with any language for writing plugins; old Vim 
needed be be compiled with support for foreign scripting languages baked into 
the binary.

Re: A value for "nothing"

[HiPhish]

After taking the advice from the mailing list users this is what I have come 
up with:

    (define-module (msgpack nil)
      #:use-module ((srfi srfi-9) #:select (define-record-type))
      #:export (nil? (get-nil . nil)))
    
    (define-record-type nil
      (make-nil)  ; The raw constructor will not get exported
      nil?)
    
    (define get-nil  ; This will be renamed on export
      (let ((the-nil (make-nil)))  ; Singleton instance
        (λ ()
          "- Scheme procedure: nil
      Return the unique object representing nothingness in MessagePack.
      
      All calls to this procedure return objects which are 'eq?' to each 
other."
          the-nil)))

The procedure `get-nil` gets exported as `nil` and returns a singleton 
instance of my `nil` type. This way `(eq? (nil) (nil))` is always `#t`. The 
only issues is that the `nil?` predicate collides with Guile's own `nil?` 
predicate, so users will have to prefix or rename it when importing. I would 
prefer not to export these two procedures with prefixes like `msgpack-nil` out 
of the box, it's really ugly :/ What is the difference between `nil?` and 
`null?` anyway? The former is not listed in the procedure index of the Guile 
manual.

What do you think?

Re: A value for "nothing"

[HiPhish]

1) Huh, I didn't think this would work because the record type is already nil, 
but apparently it does. Good to know

2) `null` is bad because the predicate would be `null?`, which collides even 
worse with Scheme. Any other suggestions? `nothing`? `nul` with one ell? I 
think it would be too easy for people to miss that one letter and be confused 
why things don't work as they should. The MessagePack spec calls the type 
`nil`:
https://github.com/msgpack/msgpack/blob/master/spec.md#nil-format


John Cowan wrote:
> 1) Some Schemes don't support rename on export.  Just give the procedure
> the name you want it to have.
> 
> 2) Please don't use nil as a name.  Many Schemers pronounce (), the
> external representation of the empty list, as "nil".  Use null or something
> else.

Re: A value for "nothing"

[John Cowan]

You're right about null? being a problem.  `Nothing` suggests an option
type.  What about 'nada' or 'nix'?

On Fri, Sep 14, 2018 at 6:45 PM HiPhish <hiphish@posteo.de> wrote:

> 1) Huh, I didn't think this would work because the record type is already
> nil,
> but apparently it does. Good to know
>
> 2) `null` is bad because the predicate would be `null?`, which collides
> even
> worse with Scheme. Any other suggestions? `nothing`? `nul` with one ell? I
> think it would be too easy for people to miss that one letter and be
> confused
> why things don't work as they should. The MessagePack spec calls the type
> `nil`:
> https://github.com/msgpack/msgpack/blob/master/spec.md#nil-format
>
>
> John Cowan wrote:
> > 1) Some Schemes don't support rename on export.  Just give the procedure
> > the name you want it to have.
> >
> > 2) Please don't use nil as a name.  Many Schemers pronounce (), the
> > external representation of the empty list, as "nil".  Use null or
> something
> > else.
>
>
>

Re: A value for "nothing"

[HiPhish]

Not a fan of either, "nada" is not English, and "nix" is a slang term, 
unlikely to be known to foreign speakers (I didn't know about it myself). How 
about "nihil", it's an inter-lingual term and close to "nil" in sound.

you wrote:
> You're right about null? being a problem.  `Nothing` suggests an option
> type.  What about 'nada' or 'nix'?

Re: A value for "nothing"

[Keith Wright]

HiPhish <hiphish@posteo.de> writes:

> Not a fan of either, "nada" is not English, and "nix" is a slang term, 
> unlikely to be known to foreign speakers (I didn't know about it myself). How 
> about "nihil", it's an inter-lingual term and close to "nil" in sound.

none? 

Re: A value for "nothing"

[Edwin Watkeys]

In previous work on validated systems in pharma manufacturing monitoring settings, there’s the concept of not available (“NAV”) for measurements which is used in contrast to not applicable (“NA”). We never used null/nil but always one of the above when describing measurements.

Edwin Watkeys; 917-324-2435.

> On Sep 15, 2018, at 14:28, Keith Wright <kwright@keithdiane.us> wrote:
> 
> HiPhish <hiphish@posteo.de> writes:
> 
>> Not a fan of either, "nada" is not English, and "nix" is a slang term, 
>> unlikely to be known to foreign speakers (I didn't know about it myself). How 
>> about "nihil", it's an inter-lingual term and close to "nil" in sound.
> 
> none? 
> 
> 

Re: A value for "nothing"

[HiPhish]

"Not available" makes it sound like there something we cannot get a hold of. 
Like you have a bag, but the contents of the bag are stuck to it, whereas 
"nothing" makes me think of a bag that's actually empty.

Edwin Watkeys wrote:
> In previous work on validated systems in pharma manufacturing monitoring
> settings, there’s the concept of not available (“NAV”) for measurements
> which is used in contrast to not applicable (“NA”). We never used null/nil
> but always one of the above when describing measurements.
> 
> Edwin Watkeys; 917-324-2435.

Re: A value for "nothing"

[Edwin Watkeys]

Yes, in a way. A measurement is NA if it is not applicable e.g. a color does not have a mass, whereas NAV is used in contexts where there is a relevant value but it was not retrieved, was lost, was recorded but is indecipherable, was recorded but was corrupted, was recorded but was eaten by the dog, or some similar reason.

The philosopher in me would say NA is an ontological nothingness whereas NAV is an epistemological nothingness.

Edwin Watkeys; 917-324-2435.

> On Sep 15, 2018, at 18:16, HiPhish <hiphish@posteo.de> wrote:
> 
> "Not available" makes it sound like there something we cannot get a hold of. 
> Like you have a bag, but the contents of the bag are stuck to it, whereas 
> "nothing" makes me think of a bag that's actually empty.
> 
> Edwin Watkeys wrote:
>> In previous work on validated systems in pharma manufacturing monitoring
>> settings, there’s the concept of not available (“NAV”) for measurements
>> which is used in contrast to not applicable (“NA”). We never used null/nil
>> but always one of the above when describing measurements.
>> 
>> Edwin Watkeys; 917-324-2435.
> 
> 

Re: A value for "nothing"

[HiPhish]

That raises to connotation that there can be multiple of something: none, one, 
many. Maybe "nothing" really is the best option. After all, "nihil" is just 
Latin for "nothing", so I might as well use English.

> none?

Re: A value for "nothing"

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]


> You're right about null? being a problem.  `Nothing` suggests an option
> type.  What about 'nada' or 'nix'?

I'd call it

	tinn
	this is not nothing

or

	tin
	this is nothing

	[ and tin, apart from the chemical, has a few of its meaning associated
	[ with the function of a 'container' (tin can, tin box ...)

but we'd loose the fun

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]