Unicode lambda Lassi Kortela (12 May 2019 10:19 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 11:18 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 11:40 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 11:50 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 12:06 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (12 May 2019 12:11 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 12:23 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 13:23 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 13:46 UTC)
Re: Unicode lambda John Cowan (12 May 2019 14:20 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 14:38 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 14:55 UTC)
Re: Unicode lambda John Cowan (12 May 2019 15:00 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 15:20 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 18:42 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 19:43 UTC)
Re: Unicode lambda John Cowan (12 May 2019 22:29 UTC)
Re: Unicode lambda Shiro Kawai (13 May 2019 10:48 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 08:25 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (14 May 2019 08:50 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 10:10 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 10:59 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 12:35 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 13:09 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 14:04 UTC)
Re: Unicode lambda Shiro Kawai (14 May 2019 19:18 UTC)
Re: Unicode lambda Vincent Manis (14 May 2019 22:01 UTC)
Re: Unicode lambda Lassi Kortela (20 May 2019 09:21 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (21 Oct 2019 14:20 UTC)
Re: Unicode lambda Shiro Kawai (21 Oct 2019 17:19 UTC)
Re: Unicode lambda John Cowan (21 Oct 2019 17:39 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (21 Oct 2019 18:43 UTC)
Re: Unicode lambda John Cowan (21 Oct 2019 23:27 UTC)
Encoding declarations Lassi Kortela (22 Oct 2019 08:39 UTC)
Re: Encoding declarations John Cowan (22 Oct 2019 20:52 UTC)
#! directives, general and specific Lassi Kortela (22 Oct 2019 09:11 UTC)
Re: #! directives, general and specific John Cowan (22 Oct 2019 20:27 UTC)
Re: #! directives, general and specific Lassi Kortela (22 Oct 2019 20:43 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (13 May 2019 08:50 UTC)
Re: Unicode lambda Lassi Kortela (13 May 2019 10:27 UTC)
Re: Unicode lambda Per Bothner (12 May 2019 14:17 UTC)
Re: Unicode lambda Peter (12 May 2019 15:06 UTC)

Re: Unicode lambda Lassi Kortela 14 May 2019 14:03 UTC

> Also Racket has things like "#lang racket/base". A more general
>
>      #!(lang whatever <options...>)
>
> might make sense.

Haskell's GHC compiler supports magic comments like this:

{-# LANGUAGE ExistentialQuantification,
              FlexibleInstances,
              GeneralizedNewtypeDeriving,
              MultiParamTypeClasses,
              TypeSynonymInstances,
              DeriveDataTypeable #-}

So we could have equivalent syntax:

#!(lang haskell
         existential-quantification
         flexible-instances
         generalized-newtype-deriving
         multi-param-type-classes
         type-synonym-instances
         derive-data-typeable)

(Not saying we should aspire to support Haskell with all those
extensions :D But the general form of directive seems robust.)

Just noticed that SRFI 10 ("#, external form") from 2000 by Oleg
Kiselyov covers the same ground we are now exploring. The idea there is
to permit things like:

     #,(pi)
     #,(NaN)
     #,(os-type)
     #,(srfi-features)

The general form specified is #,(<tag> <datum>*). Clearly we are
standing on the shoulders of the same giants.

The #,(foo) form is meant to evaluate to an object so it would be
different from #!(foo) which is meant to control the reader or write
metadata that is discarded by the reader. But anyway #,(foo) is from the
time of R5RS and is not compatible with R6RS and syntax-case which uses
#,<datum> as an abbreviation of (unsyntax <datum>). R7RS-small does not
reserve #,(foo).

Per later published SRFI 108 (Named quasi-literal constructors) in 2013.
It discusses SRFI 10 and mentions that 108 evaluates its &symbol{...} at
eval time whereas SRFI 10 evaluates its #,(symbol ...) at read time. The
{...} is also a string instead of an S-expression.