tools.reader

Feature Expressions

Details

  • Type: Enhancement Enhancement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Patch:
    Code and Test

Description

Feature expressions based directly on Common Lisp.

Implementation based on Roman's patch for CLJS-27. #+ #- and or not are supported. Unreadable tagged literals are suppressed through suppress-read.

For example, reading the following with features set to #{:clojure} returns :baz

#+bad/platform #foo bar :baz

I didn't provide a default set of features, but #{:clojure} isn't a bad start.

CLJ-1424 is the accompanying patch for Clojure.

Activity

Ghadi Shayban made changes -
Field Original Value New Value
Description Feature expressions based directly on Common Lisp.

Implementation based on Roman's patch for CLJS-27. #+ #- and or not are supported. Unreadable tagged literals are suppressed through *suppress-read*.

For example, reading the following with features set to #{:clojure} returns :baz

#+bad/platform #foo bar :baz

I didn't provide a default set of *features*, but #{:clojure} isn't a bad start.
Feature expressions based directly on Common Lisp.

Implementation based on Roman's patch for CLJS-27. #+ #- and or not are supported. Unreadable tagged literals are suppressed through *suppress-read*.

For example, reading the following with features set to #{:clojure} returns :baz

#+bad/platform #foo bar :baz

I didn't provide a default set of *features*, but #{:clojure} isn't a bad start.

CLJ-1424 is the accompanying patch for Clojure.
Hide
Nicola Mometto added a comment - - edited

I looked over the patch and it mostly looks good, a few comments:

  • does *suppress-read* need to be exposed?
  • can you add a docstring for *features*?
  • should *suppress-read* affect read-eval?

That said, has it been decided that this is how feature expressions will be implemented in 1.7?
If not, I'm going to wait to merge this in until a decision is taken, this is a major design point and I don't want to diverge from the official clojure take on this even for a single release: people might start using it, especially since t.r is now the default reader for cljs.

Show
Nicola Mometto added a comment - - edited I looked over the patch and it mostly looks good, a few comments:
  • does *suppress-read* need to be exposed?
  • can you add a docstring for *features*?
  • should *suppress-read* affect read-eval?
That said, has it been decided that this is how feature expressions will be implemented in 1.7? If not, I'm going to wait to merge this in until a decision is taken, this is a major design point and I don't want to diverge from the official clojure take on this even for a single release: people might start using it, especially since t.r is now the default reader for cljs.
Hide
Ghadi Shayban added a comment -

Yes thank you for not merging. This is WIP and just one approach for feature expressions. There seem to be at least two couple diverging approaches emerging from the various discussion (Brandon Bloom's idea of read-time splicing being the other.) I would definitely not merge until the community and Rich weighs in.

In any case having all Clojure platforms be ready for the change is probably essential. Also backwards compatibility of feature expr code to Clojure 1.6 and below is also not trivial.

1) *suppress-read* probably doesn't need to be exposed
2) *suppress-read* should probably imply *read-eval* false. You wouldn't want read-ctor to load any classes or call any code or constructors

Show
Ghadi Shayban added a comment - Yes thank you for not merging. This is WIP and just one approach for feature expressions. There seem to be at least two couple diverging approaches emerging from the various discussion (Brandon Bloom's idea of read-time splicing being the other.) I would definitely not merge until the community and Rich weighs in. In any case having all Clojure platforms be ready for the change is probably essential. Also backwards compatibility of feature expr code to Clojure 1.6 and below is also not trivial. 1) *suppress-read* probably doesn't need to be exposed 2) *suppress-read* should probably imply *read-eval* false. You wouldn't want read-ctor to load any classes or call any code or constructors

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated: