Giter Club home page Giter Club logo

atto-lisp's People

Contributors

hvr avatar kowey avatar nominolo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

atto-lisp's Issues

escapes in symbols

This is already present as a TODO in the source code, but I thought maybe an issue would be useful to track it and put some notes down.

As I understand it, we would need to worry about 3 things: single escape characters (, with NB \n meaning 'n' and not 'newline char'), multi-escape characters (|Jurassic Park|), and package markers (Films::|Jurassic Park|).

Package markers may be tricky. We may need to change from Symbol Text to Symbol (Maybe Text) Text. So

  • |Jurassic Park| becomes Symbol Nothing "Jurassic Park",
  • :title becomes Symbol (Just "KEYWORD") "title", and
  • Films::|Jurassic Park| becomes Symbol (Just "Films") "Jurassic Park".

Alternatively, a package marker type, which may be less yucky than having the "KEYWORD"convention (technically true as it may be, IIUC correctly, they do literally go into the KEYWORD package)

Some random/not-too-useful self-expression: I like the HyperSpec, but find it quite confusing to navigate. I think I wish it had fewer hyperlinks, and they all pointed to the spec itself instead of the glossary

attoparsec upper bound

Just one more upper bound I've found:

attoparsec-0.13.0.1 depended on by:
- atto-lisp-0.2.2.1 (>=0.10 && < 0.13). No maintainer. @nominolo

build error (GHC 6.12.3)

Hi Thomas,

One of my users reports the following build error with GHC 6.12.3. Do you think it's an easy fix? Thanks! :-)

Data/AttoLisp.hs:1:0:
    Couldn't match expected type `c' against inferred type `b'
      `c' is a rigid type variable bound by
          the instance declaration at Data/AttoLisp.hs:308:34
      `b' is a rigid type variable bound by
          the instance declaration at Data/AttoLisp.hs:308:32
    When using functional dependencies to combine
      ParseList b b,
        arising from a use of `parseList' at Data/AttoLisp.hs:312:4-25
      ParseList b c,
        arising from the instance declaration at Data/AttoLisp.hs:308:9-59

Data/AttoLisp.hs:309:2:
    Couldn't match expected type `c' against inferred type `b'
      `c' is a rigid type variable bound by
          the instance declaration at Data/AttoLisp.hs:308:34
      `b' is a rigid type variable bound by
          the instance declaration at Data/AttoLisp.hs:308:32
    When using functional dependencies to combine
      ParseList a a,
        arising from the dependency `a -> b'
        in the instance declaration at Data/AttoLisp.hs:314:9
      ParseList b c,
        arising from a use of `parseList' at Data/AttoLisp.hs:312:4-25
    When generalising the type(s) for `parseList'
    In the instance declaration for `ParseList (a -> b) c'

Data/AttoLisp.hs:312:4:
    Overlapping instances for ParseList b b
      arising from a use of `parseList' at Data/AttoLisp.hs:312:4-25
    Matching instances:
      instance ParseList a a -- Defined at Data/AttoLisp.hs:314:9-21
      instance (FromLisp a, ParseList b c) => ParseList (a -> b) c
        -- Defined at Data/AttoLisp.hs:308:9-59
    (The choice depends on the instantiation of `b'
     To pick the first instance above, use -XIncoherentInstances
     when compiling the other instance declarations)
    In the expression: parseList msg (f y) xs
    In the expression:
        do { y <- parseLisp x;
             parseList msg (f y) xs }
    In the definition of `parseList':
        parseList msg f (x : xs)
                    = do { y <- parseLisp x;
                           parseList msg (f y) xs }
cabal: Error: some packages failed to install:
atto-lisp-0.2 failed during the building phase. The exception was:
ExitFailure 1

Restrictive upper bounds prevent inclusion in Stackage

@chrisdone just sent a pull request to Stackage that pulls in atto-lisp. Some atto-lisp upper bounds prevent this from happening:

atto-lisp-0.2.1.2 (Chris Done @nominolo) cannot use:

  • attoparsec-0.12.1.2 -- >=0.8.5.1 && <0.11
  • text-1.1.1.3 -- >=0.10 && <0.12

Would it be possible to relax these upper bounds and release a new version to Hackage?

missing Semigroup instances for compilation with ghc-8.4

[1 of 1] Compiling Data.AttoLisp    ( Data/AttoLisp.hs, dist/build/Data/AttoLisp.o )

Data/AttoLisp.hs:157:10: error:
    • No instance for (Semigroup (Parser a))
        arising from the superclasses of an instance declaration
      There are instances for similar types:
        instance Semigroup (Data.Attoparsec.Internal.Types.Parser i a)
          -- Defined in ‘Data.Attoparsec.Internal.Types’
    • In the instance declaration for ‘Monoid (Parser a)’
    |
157 | instance Monoid (Parser a) where
    |          ^^^^^^^^^^^^^^^^^

Data/AttoLisp.hs:210:10: error:
    • No instance for (Semigroup (Result a))
        arising from the superclasses of an instance declaration
    • In the instance declaration for ‘Monoid (Result a)’
    |
210 | instance Monoid (Result a) where
    |          ^^^^^^^^^^^^^^^^^

with ghc-9.2: Non type-variable argument in the constraint: TypeCast f HTrue

cabal -w/opt/ghc/ghc-9.2.1.20220211/bin/ghc test
...
Data/AttoLisp.hs:358:10: error:
    • Non type-variable argument in the constraint: TypeCast f HTrue
      (Use FlexibleContexts to permit this)
    • In the instance declaration for ‘IsFunction (x -> y) f’
    |
358 | instance TypeCast f HTrue => IsFunction (x -> y) f
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

support for some Common Lisp reader macros

It may be useful to provide some support for a handful of reader macros. For example, maybe things like #S(film :title "Jaws" :director "Steven Spielberg") should be interpreted as though they were (make-film :title "Jaws" :director "Steven Spielberg"). I don't claim to understand how they are supposed to be understood, BTW, this is just the result of typing things into SBCL and seeing what we get back

It's possible that this is thing is so specific to Common-Lisp that we'll need to ask ourselves some questions about what atto-lisp is supposed to do about the existence of multiple Lisp dialects

PS. hope this isn't spammy for you. Should be my last thought for the day. Thanks!

multiple lisp dialects?

I think it could be useful first to explicitly decide if we want atto-lisp to be specific to a dialect of Lisp (I'm using Common Lisp for now), or if we're trying to be flexibly support multiple dialects (within reason, not trying to go all out here)

If the latter, would an hierarchy like

  • Data.AttoLisp - universal stuff
    • Data.AttoLisp.CL
    • Data.AttoLisp.Scheme

make sense? The idea is that each Data.AttoLisp.Foo would export the same interface as Data.AttoLisp (and actually import the bits and pieces from it that more or less work the same across lisps). One thing we may have to watch out for is if the Lisp type would gracefully support the dialects people care about.

deepseq 1.4 support

This is currently blocking Stackage from moving to GHC 7.10. Would you be able to relax the upper bound?

Inaccurate version bounds

See below

atto-lisp

I've already fixed up the metadata for the respective release on Hackage at

Please take this into account for future releases of atto-lisp

I've noticed that atto-lisp is generally missing version bounds on its dependencies which will sooner or later become a problem. Please help us keep Hackage in a good shape for its users as well as make our job as Hackage Trustees easier by maintaining accurate version bounds.

You can inspect the current build report matrix at https://matrix.hackage.haskell.org/package/atto-lisp

location info

Hi, I want to add source location info to expressions. Should I make a PR, or fork the project?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.