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