[plt-scheme] More fun with typed scheme: attempt to write vector-join and a minor rant

Nope, that's a very long term goal possibly better suited for
Matthew's or Robby's group than mine. But Sam and Stevie will
push the type system so that the compiler can take advantage
of it  when Matthew knows how to do so -- Matthias

p.s. Currently we use the PLT bug/feature management system
to track Typed Scheme bugs and feature requests. Changing the
compiler to accommodate the type system does not fall in this
category however.




On Nov 2, 2009, at 9:07 AM, Scott McLoughlin wrote:

> Matthias,
>
> Is there a bug tracking system with a section for typed-scheme of  
> which I'm
> unaware?
>
> I know it's not in the list of goals stated below, but it would be  
> wicked cool
> if typed-scheme could generate byte codes/JIT code that completely  
> bypassed
> now no longer necessary type checking  on functions/primitives/ 
> etc. :-)
>
> Scott
>
>
> Matthias Felleisen wrote:
>>
>> 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
>>
>>
>>
>
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme