Re: [racket-users] iso-recursive types not allowed in TR?

[Alexander D. Knauth]

On Jun 13, 2015, at 8:18 AM, Hendrik Boom  wrote:
> On Fri, Jun 12, 2015 at 06:06:05PM -0700, 'John Clements' via users-redirect 
> wrote:
>> On Jun 12, 2015, at 5:52 PM, Alexander D. Knauth  
>> wrote:
>>> On Jun 12, 2015, at 8:30 PM, 'John Clements' via users-redirect 
>>>  wrote:
>>> 
 (define-type (HuffJsexpr T)
 (U T (HashTable Symbol HuffJsexpr)))
>>> 
>>> Do you mean this?
>>> (define-type (HuffJsexpr T)
>>> (U T (HashTable Symbol (HuffJsexpr T

>> Actually, I also can’t believe that TR allowed me to use a type constructor 
>> without an argument like that.
> 
> Maybe the type definitions need to be type-checked, too?
> 
> -- hendrik

I was thinking about this and I was coming up with an explanation of why it 
wouldn’t work (the way TR is currently set up), but then I realized there could 
be a way of doing this that makes sense without restructuring TR, so …

First, the reason I thought it might not work: In TR a type constructor and a 
polymorphic type are the same thing. And that makes sense because it makes 
sense to instantiate polymorphic types as if they were type constructors.
But that means that when it comes across a type constructor, it sees it as a 
polymorphic type, so it doesn’t raise a type error.

But type constructors like this don’t always make sense as polymorphic types, 
because polymorphic types only really make sense when there is something in the 
value with that type that can take some kind of input, like a function, some 
data structure containing a function, an object, or even something that could 
be mutable, I guess? I’m not sure. Anyway that could be something that TR could 
check for in this kind of thing, but it seems like it could be complicated? 
Again I’m not sure.

Or would it be simpler to just separate type constructors from polymorphic 
types completely, but allow polymorphic types to be used as type constructors 
as well for backwards compatibility?  But that could involve …

Actually, I was I about to say that would probably involve restructuring a lot 
of the type checker, but then I thought maybe type constructors could be a 
container type that contains a “polymorphic” type, and when it is “applied" the 
type-checker would just ignore this and look at the “polymorphic” type inside, 
but in a situation that requires an actual “non-constructor” type, it would 
raise a type error?  But then what if you wanted to define a type constructor 
that accepts type constructors as arguments (a higher-order type-constructor)?  
Again, it seems like this could also be complicated?

I’m not sure what the best thing to do is. 

Would bounded polymorphism help to solve this?  Or would it require another 
whole type system for types and type constructors?

Sorry if this doesn’t make much sense. I’m sending it anyway.


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] iso-recursive types not allowed in TR?

['John Clements' via users-redirect]

> On Jun 13, 2015, at 7:37 AM, Alexander D. Knauth  wrote:
> 
> 
> On Jun 13, 2015, at 12:18 AM, 'John Clements' via users-redirect 
>  wrote:
> 
>> Okay, I shouldn’t change topics, but while I’ve got you (guys): it looks 
>> like (module+ test …) now works in TR, but not when there are imported 
>> bindings… suppose I have foo.rkt:
> 
> I’ve run into similar problems with module+ before as you did below, but I 
> found that something like this has worked so far:
> (module* test racket/base
>  (require (submod “..”) rackunit)
>  … tests here …
>  )

Ah! Makes perfect sense. The submodule isn’t in typed racket by default. 

John

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] 3d-syntax and sharing values between "read-time" and run-time?

[Alexander D. Knauth]

I just tried doing something for Asumu Takikawa’s `#lang clojure` with reading 
sets.

In the reader module #{1 2 3} is read, and the reader returns a syntax object 
created with
(datum->syntax … (list->set …) …)

And then if I write (quote #{1 2 3}), it actually works?

I’m a bit pleasantly surprised, because I was pretty sure this would fail with 
some kind of error related to 3d-syntax.

Is there a reason why this should always work?

Or is there a situation where this will sometimes fail?


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] DrRacket stubbornly indents code as if it were Racket

[Yuhao Dong]

Greetings Racketeers,
I'm trying to make my own #lang that has a non-sexp syntax, like Scribble. 
However, the problem is the DrRacket always tries to indent my code as if it 
were Racket, which is extremely unusable and annoying.
Since changing DrRacket's indenting behaviors seems undocumented, I looked at 
how Scribble did it, and then I put what I thought must be correct code here:
https://github.com/quantum1423/mir/blob/master/lang/reader.rkt
However, DrRacket still indents my code as if it were Racket, although it does 
turn off syntax highlighting correctly. I added the with-output-to-file line to 
see if the drracket:indentation branch is ever executed, but apparently it 
isn't.
How does Scribble manage to get DrRacket to indent it in a non-sexp way?
Thanks!Yuhao Dong 

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.