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.