[plt-scheme] More fun with typed scheme: attempt to write vector-join and a minor rant
Scott, as I said in a private email, please by all means
submit bug reports and feature requests for Typed Scheme.
We have reached our first goal -- a typed variant for
"list Scheme" that accommodates many of the existing
idioms -- and we're far from the full goal -- support
all of Scheme with a truly accommodating type system.
There are many ways in which we are 'stuck':
1. Sam has to wrap up his PhD and transition to a real job.
2. Just in case he ends up sweeping floors at Sun, I
have brought Stevie in for the second round so that there
is a second person on the project. (I don't really count.)
Plus two or three maintainers is always better than one.
3. My long term goal is to turn Typed Scheme into a full
fledge language BUT I am sure we canNOT reach the true
long term goal. So I will always have something to do :-)
4. Technically: we are missing a few pieces of core Scheme
semantics. Sam wrote to you that he is working on vectors.
We are missing classes and units. Especially the first
are critical for our code base, which is our guidance
system for the development of Typed Scheme.
Ideally, we should create a macro system that allows the
addition of types. Until we know what we need (explore
before you abstract!) we will develop these two "by hand".
That's Stevie's job.
Otherwise we will use real bug reports and real feature
requests as our 'guidance system'.
-- Matthias
On Nov 2, 2009, at 1:17 AM, Scott McLoughlin wrote:
> Or vector-append - but in any case, just a function that creates
> a single (Vectorof a) out a bunch of other (Vectorof a) arguments
> passed as rest arguments.
>
> So the signature is.
>
> (define: (a) (vector-join . [vecs : (Vectorof a) *]) : (Vectorof a)
>
> A blow by blow of the type errors is impossible at this point
> (unless Dr.
> Scheme has a logging feature of which I'm not aware.)
>
> But futzing around, (1) I first recalled from previous emails that
> some
> vector routines weren't "type-schemed" yet, so I wrote my own vector-
> >list
> called tvector->list. Lovely routine, but that didn't do the trick.
>
> Then I recalled reading the cool paper on the typed-scheme type system
> and how it handled, with near pure genius, higher order variable arity
> routines such as "map." So, hmmm, I thought, and wrote my own nicely
> type-schemed "map1" which just did the job for a single list and
> nothing
> else fancy. That works lovely too, as it well should.
>
> ;;; tvector->list isn't a challenge
> (tvector->list #(2 3))
> (2 3)
>
>
> ;;; No general problem with map1
> (map1 string->symbol (list "ffdsaf" "d"))
> (ffdsaf d)
>
> Nevertheless, combining map or map1 with vector->list or tvector-
> >list give nearly
> identical error messages.
> ;;; Original map type check error
> (map vector->list (list #(2) #(1)))
> typecheck: Polymorphic function map could not be applied to arguments:
> Domain: (a b ... b -> c) (Listof a) (Listof b) ... b
> Arguments: (All (a) ((Vectorof a) -> (Listof a))) (List (Vectorof
> Integer) (Vectorof Integer))
> in: (#%app map vector->list (#%app list (quote #(2)) (quote #(1))))
>
> ;;; My map1 type check error, this type using tvector->list
> (map1 vector->list (list #(2) #(1)))
> typecheck: Polymorphic function map1 could not be applied to
> arguments:
> Domain: (a -> b) (Listof a)
> Arguments: (All (a) ((Vectorof a) -> (Listof a))) (List (Vectorof
> Integer) (Vectorof Integer))
> in: (#%app map1 tvector->list (#%app list (quote #(2)) (quote #(1))))
>
>
> So anyway, imagine lots of futzing and testing, breaking down each
> little
> part, of an already really short function to begin with, and making
> sure it
> works. But alas, unless I'm terribly distracted by Next Iron Chef,
> I think there's
> some other reason I'm coming up empty handed.
>
> So any guidance, greatly appreciated.
>
> OH OH OH OH - One last little thing that actually does tick off my
> normally
> serene demeanor. As I understand it, (List a b c) is basically a
> tuple and
> (Listof a) is a list of type a.
> Well, unless I'm missing something, and yes, I certainly might be,
> the error messages
> you'll see above report rest arguments as if they were tuples: (List
> (Vec...) (Vec...)).
>
> Maybe there's some great reason for this, but it's yet another
> "undocumented feature"
> of typed-scheme that caused untold amounts of unnecessary staring at
> the screen and drooling
> on the keyboard on my part.
>
> Anyway, I LOVE the idea of typed scheme, and could even imagine
> loving WORKING with it, but given
> that nearly every time I've touched it I've had to post to this list
> and retrieved a response akin
> to, "Oh yeah, sorry, that's not really 100% yet," maybe it would be
> kinder to those whose
> time is actually worth something to actually pull the plug on the
> beloved feature until it gets
> the 1000's of test cases, ~50 pages of introductory tutorial and
> ~200+ pages of detailed
> documentation that the (otherwise nifty) language deserves.
> I don't mean to be bitchy, just logical. How many pages is R6RS and
> with what care was that
> documentation written? Hate the "big scheme"? Ok, heck, just take
> R5RS as an example if one
> prefers and count up its written pages along with the tons and tons
> and tons of person-hours
> of deliberation in its making.
>
> And neither of *those* teeny weeny tiny little languages have typed-
> scheme's complex manifest type
> system to fully describe, shine blindingly bright illumination on
> every corner case, and so on and
> so forth.
> Anyway, I'd MUCH rather just have typed-scheme work 95++ % of the
> time or at least see a
> carefully constructed and published road map regarding both HOW and
> WHEN type-scheme might
> finally achieve this level of ready for "prime time" status.
>
> Scott
>
> p.s. Yeah, part of my past experience has been as both a project
> mgmt puke, and worse, as a CEO -
> so if I sound like one, sue me :-)
>
> p.p.s. The reason I give a hoot at all is because I'm really hoping
> to use typed scheme to write
> non-trivial parts of a compiler, including a CPS style back end, and
> going back to the drawing
> board on the tools selection front of the project isn't really
> inviting.
>
>
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme