Re: [racket-users] Simple Interdependent Units?
Il giorno 26/mag/2015, alle ore 17.11, Matthias Felleisen ha scritto: > > On May 26, 2015, at 11:00 AM, Michael Tiedtke > wrote: > >> >> Il giorno 26/mag/2015, alle ore 14.17, Matthias Felleisen ha scritto: >> >>> >>> On May 26, 2015, at 1:10 AM, Michael Tiedtke wrote: >>> Sorry, ut I call it a workaround. >>> >>> >>> Please read up on programming language design. >>> >> >> >> I consider the term programming language to be some kind of marketing label. >> Codings systems and their abstraction sometimes even capture concepts ... >> othertimes it's syntactic sugar. > > > Please read up on programming language design. I am sorry for repeating > myself. > Yes, they all start out with maths but I would base it on music with repeat instead of loop just to eventually see a lot of playing cards on my virtual music rack. ;-) Well strings might be useful, too. -- 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] Simple Interdependent Units?
On May 26, 2015, at 1:10 AM, Michael Tiedtke wrote: > Sorry, ut I call it a workaround. Please read up on programming language design. -- 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] Simple Interdependent Units?
Il giorno 25/mag/2015, alle ore 21.56, Matthias Felleisen ha scritto:
...
>> Yes, I was thinking about things like these in my other message. But
>> this alreaddy depends on the evaluation order which can be "reversed".
>> Right in this example one would like to mix in lazy evaluation.
>>
>> (define the-view
>> {with-lazy-evaluation (new view% #model: (new model% #view: the-view)) })
>
> There is a difference between lazy evaluation and cyclic references.
> And it's huge.
>
In the specific example lazy evaluation would do the job, though.
>
>> One might even think about an interpreter that automatically tries ...
>
> See shared. That's NOT laziness. Repeat, it's NOT laziness.
>
Cyclic references or mutual hosting objects are not a problem at all.
It's only when you want the evualator handle that one line definition. But
a lazy evaluator solves this problem which a lot of people stumble over
as long as they have not yet adapted their way of thinking to the machine.
>
> Here is what it takes (in principle) to extend it to objects:
>
> (define-syntax (object-shared stx)
> (syntax-case stx (new)
> [(_ [(x x-field (new x% [x-field_ x0]))
>(y y-field (new y% [y-field_ y0]))]
> body)
>#'(letrec ([x (new x% [x-field '*undefined-x*])]
>[y (new y% [y-field y0])])
>(set-field! x-field x x0)
>#;
>(set-field! y-field y y0)
>body)]))
>
> (define the-view
> (object-shared [(the-model view (new model% [view the-view]))
> (the-view model (new view% [model the-model]))]
>the-view))
>
>
Sorry, ut I call it a workaround.
(define my-view (new view% #model: null))
(define my-model (new model% #view: null))
(send my-view set-model my-model)
(send my-model set-view my-view)
Every view should be able to handle a null or void model and every
model should be detachable from the view 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] Simple Interdependent Units?
No.
On May 25, 2015, at 6:59 PM, Luke Whittlesey wrote:
> Would lazy-require work here?
>
> http://docs.racket-lang.org/reference/lazy-require.html
>
> On Mon, May 25, 2015 at 3:56 PM, Matthias Felleisen
> wrote:
>
> On May 25, 2015, at 3:19 PM, Michael Tiedtke
> wrote:
>
> > See, you're doing away with the class definitions and substitute them with
> > unit definitions.
> > This is what I meant when I wrote you recreated encapsulation and
> > inheritance. (Because
> > linking somehow resembles multiple inheritance.)
>
>
> #lang racket/gui
>
> (define-signature model^ (setter get))
> (define-signature view^ (error))
>
> ;; decoupled model-view
> (define model@
> (unit (import view^)
> (export model^)
>
> (define model%
> (class object%
> (super-new)
> (define the-number 12)
> (define/public (setter v)
> (when (or (< v 0) (> 0 100))
> (error "can't do that"))
> (displayln `(setting to ,v))
> (set! the-number v))
> (define/public (get)
> the-number)))
>
> (define model (new model%))
>
> (define (setter v) (send model setter v))
> (define (get) (send model get
>
> (define view@
> (unit (import model^)
> (export view^)
>
> (define view%
> (class object%
> (super-new)
> (define frame (new frame% [width 100][height 200][label "VW"]))
> (define vpane (new vertical-pane% [parent frame]))
> (define value0 (get))
> (define slide
> (new slider%
>[parent vpane] [label "%"]
>[min-value 0] [init-value value0] [max-value 100]
>[style '(vertical)]
>[callback (lambda (self _e) (setter (send self
> get-value)))]))
> (define/public (error msg)
> (displayln msg))
> (send frame show #t)))
>
> (define (error msg) (send view error msg))
> (define view (new view%
>
> (define completly-linked-program@
> (compound-unit
> (import)
> (export)
> (link
> [((model : model^)) model@ view]
> (((view : view^)) view@ model
>
> (define (run)
> (invoke-unit completly-linked-program@))
>
>
>
> > Include works best after a cut&paste operation on an over-grown file.
> > My favourite "module system" for now!
>
>
> Please see previous email.
>
> > Yes, I was thinking about things like these in my other message. But
> > this alreaddy depends on the evaluation order which can be "reversed".
> > Right in this example one would like to mix in lazy evaluation.
> >
> > (define the-view
> > {with-lazy-evaluation (new view% #model: (new model% #view: the-view)) })
>
> There is a difference between lazy evaluation and cyclic references.
> And it's huge.
>
>
> > One might even think about an interpreter that automatically tries ...
>
> See shared. That's NOT laziness. Repeat, it's NOT laziness.
>
>
> Here is what it takes (in principle) to extend it to objects:
>
> (define-syntax (object-shared stx)
> (syntax-case stx (new)
> [(_ [(x x-field (new x% [x-field_ x0]))
> (y y-field (new y% [y-field_ y0]))]
> body)
> #'(letrec ([x (new x% [x-field '*undefined-x*])]
> [y (new y% [y-field y0])])
> (set-field! x-field x x0)
> #;
> (set-field! y-field y y0)
> body)]))
>
> (define the-view
> (object-shared [(the-model view (new model% [view the-view]))
> (the-view model (new view% [model the-model]))]
> the-view))
>
>
> Git pull request for complete extension welcome.
>
>
>
>
>
>
>
>
>
> --
> 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.
>
--
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] Simple Interdependent Units?
Would lazy-require work here?
http://docs.racket-lang.org/reference/lazy-require.html
On Mon, May 25, 2015 at 3:56 PM, Matthias Felleisen
wrote:
>
> On May 25, 2015, at 3:19 PM, Michael Tiedtke
> wrote:
>
> > See, you're doing away with the class definitions and substitute them
> with unit definitions.
> > This is what I meant when I wrote you recreated encapsulation and
> inheritance. (Because
> > linking somehow resembles multiple inheritance.)
>
>
> #lang racket/gui
>
> (define-signature model^ (setter get))
> (define-signature view^ (error))
>
> ;; decoupled model-view
> (define model@
> (unit (import view^)
> (export model^)
>
> (define model%
> (class object%
> (super-new)
> (define the-number 12)
> (define/public (setter v)
> (when (or (< v 0) (> 0 100))
> (error "can't do that"))
> (displayln `(setting to ,v))
> (set! the-number v))
> (define/public (get)
> the-number)))
>
> (define model (new model%))
>
> (define (setter v) (send model setter v))
> (define (get) (send model get
>
> (define view@
> (unit (import model^)
> (export view^)
>
> (define view%
> (class object%
> (super-new)
> (define frame (new frame% [width 100][height 200][label "VW"]))
> (define vpane (new vertical-pane% [parent frame]))
> (define value0 (get))
> (define slide
> (new slider%
>[parent vpane] [label "%"]
>[min-value 0] [init-value value0] [max-value 100]
>[style '(vertical)]
>[callback (lambda (self _e) (setter (send self
> get-value)))]))
> (define/public (error msg)
> (displayln msg))
> (send frame show #t)))
>
> (define (error msg) (send view error msg))
> (define view (new view%
>
> (define completly-linked-program@
> (compound-unit
> (import)
> (export)
> (link
> [((model : model^)) model@ view]
> (((view : view^)) view@ model
>
> (define (run)
> (invoke-unit completly-linked-program@))
>
>
>
> > Include works best after a cut&paste operation on an over-grown file.
> > My favourite "module system" for now!
>
>
> Please see previous email.
>
> > Yes, I was thinking about things like these in my other message. But
> > this alreaddy depends on the evaluation order which can be "reversed".
> > Right in this example one would like to mix in lazy evaluation.
> >
> > (define the-view
> > {with-lazy-evaluation (new view% #model: (new model% #view: the-view))
> })
>
> There is a difference between lazy evaluation and cyclic references.
> And it's huge.
>
>
> > One might even think about an interpreter that automatically tries ...
>
> See shared. That's NOT laziness. Repeat, it's NOT laziness.
>
>
> Here is what it takes (in principle) to extend it to objects:
>
> (define-syntax (object-shared stx)
> (syntax-case stx (new)
> [(_ [(x x-field (new x% [x-field_ x0]))
> (y y-field (new y% [y-field_ y0]))]
> body)
> #'(letrec ([x (new x% [x-field '*undefined-x*])]
> [y (new y% [y-field y0])])
> (set-field! x-field x x0)
> #;
> (set-field! y-field y y0)
> body)]))
>
> (define the-view
> (object-shared [(the-model view (new model% [view the-view]))
> (the-view model (new view% [model the-model]))]
> the-view))
>
>
> Git pull request for complete extension welcome.
>
>
>
>
>
>
>
>
>
> --
> 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.
>
--
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] Simple Interdependent Units?
On May 25, 2015, at 3:19 PM, Michael Tiedtke
wrote:
> See, you're doing away with the class definitions and substitute them with
> unit definitions.
> This is what I meant when I wrote you recreated encapsulation and
> inheritance. (Because
> linking somehow resembles multiple inheritance.)
#lang racket/gui
(define-signature model^ (setter get))
(define-signature view^ (error))
;; decoupled model-view
(define model@
(unit (import view^)
(export model^)
(define model%
(class object%
(super-new)
(define the-number 12)
(define/public (setter v)
(when (or (< v 0) (> 0 100))
(error "can't do that"))
(displayln `(setting to ,v))
(set! the-number v))
(define/public (get)
the-number)))
(define model (new model%))
(define (setter v) (send model setter v))
(define (get) (send model get
(define view@
(unit (import model^)
(export view^)
(define view%
(class object%
(super-new)
(define frame (new frame% [width 100][height 200][label "VW"]))
(define vpane (new vertical-pane% [parent frame]))
(define value0 (get))
(define slide
(new slider%
[parent vpane] [label "%"]
[min-value 0] [init-value value0] [max-value 100]
[style '(vertical)]
[callback (lambda (self _e) (setter (send self
get-value)))]))
(define/public (error msg)
(displayln msg))
(send frame show #t)))
(define (error msg) (send view error msg))
(define view (new view%
(define completly-linked-program@
(compound-unit
(import)
(export)
(link
[((model : model^)) model@ view]
(((view : view^)) view@ model
(define (run)
(invoke-unit completly-linked-program@))
> Include works best after a cut&paste operation on an over-grown file.
> My favourite "module system" for now!
Please see previous email.
> Yes, I was thinking about things like these in my other message. But
> this alreaddy depends on the evaluation order which can be "reversed".
> Right in this example one would like to mix in lazy evaluation.
>
> (define the-view
> {with-lazy-evaluation (new view% #model: (new model% #view: the-view)) })
There is a difference between lazy evaluation and cyclic references.
And it's huge.
> One might even think about an interpreter that automatically tries ...
See shared. That's NOT laziness. Repeat, it's NOT laziness.
Here is what it takes (in principle) to extend it to objects:
(define-syntax (object-shared stx)
(syntax-case stx (new)
[(_ [(x x-field (new x% [x-field_ x0]))
(y y-field (new y% [y-field_ y0]))]
body)
#'(letrec ([x (new x% [x-field '*undefined-x*])]
[y (new y% [y-field y0])])
(set-field! x-field x x0)
#;
(set-field! y-field y y0)
body)]))
(define the-view
(object-shared [(the-model view (new model% [view the-view]))
(the-view model (new view% [model the-model]))]
the-view))
Git pull request for complete extension welcome.
--
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] Simple Interdependent Units?
Il giorno 25/mag/2015, alle ore 19.31, Matthias Felleisen ha scritto:
>
> If you mean you want truly decoupled views and models, you'd end up in this
> position:
>
> #lang racket
>
>
> ;; decoupled model-view
> (module model racket
> (provide model%)
>
> (define model%
>(class object%
> (init-field view)
> (super-new)
> (define the-number 12)
> (define/public (setter v)
>(when (or (< v 0) (> 0 100))
> (send view error "can't do that"))
>(set! the-number v))
> (define/public (get)
>the-number
>
> (module view racket/gui
> (provide view%)
>
> (require (submod ".." model))
>
> (define view%
>(class object%
> (init-field model)
> (define frame (new frame% [width 100][height 200][label "VW"]))
> (define vpane (new vertical-pane% [parent frame]))
> (define value0 (send model get))
> (define slide
>(new slider%
> [parent vpane] [label "%"]
> [min-value 0] [init-value value0] [max-value 100]
> [style '(vertical)]))
> (define/public (error msg)
>(displayln msg))
>
> (send frame show #t
>
> ;;
> -
> (require 'view 'model)
>
> (define the-view (new view% [model (new model% [view the-view])]))
>
>
>
> If you run this code and then call make-voew in the repl, you get an error
> about the use of the value the-view before its initialization.
Yes, I was thinking about things like these in my other message. But
this alreaddy depends on the evaluation order which can be "reversed".
Right in this example one would like to mix in lazy evaluation.
(define the-view
{with-lazy-evaluation (new view% #model: (new model% #view: the-view)) })
One might even think about an interpreter that automatically tries ...
>
> ;;
>
> So here is how you do it with units:
>
> #lang racket/gui
>
> (define-signature model^ (setter get))
> (define-signature view^ (error))
>
> ;; decoupled model-view
> (define model@
> (unit (import view^)
>(export model^)
>;; ---
>(define the-number 12)
>(define (setter v)
> (when (or (< v 0) (> 0 100))
>(error "can't do that"))
> (displayln `(setting to ,v))
> (set! the-number v))
>(define (get)
> the-number)))
>
> (define view@
> (unit (import model^)
>(export view^)
>
>(define frame (new frame% [width 100][height 200][label "VW"]))
>(define vpane (new vertical-pane% [parent frame]))
>(define value0 (get))
>(define slide
> (new slider%
> [parent vpane] [label "%"]
> [min-value 0] [init-value value0] [max-value 100]
> [style '(vertical)]
> [callback (lambda (self _e) (setter (send self get-value)))]))
>(define (error msg)
> (displayln msg))
>
>;; run program run
>(send frame show #t)))
>
> (define completly-linked-program@
> (compound-unit
>(import)
>(export)
>(link
> [((model : model^)) model@ view]
> (((view : view^)) view@ model
>
> (define (run)
> (invoke-unit completly-linked-program@))
>
> ;; ---
See, you're doing away with the class definitions and substitute them with unit
definitions.
This is what I meant when I wrote you recreated encapsulation and inheritance.
(Because
linking somehow resembles multiple inheritance.)
>
> Now if you just want two modules with classes that can send message to each
> other, assuming that they get objects of the right kind, that's
> straightforward:
>
> #lang racket
>
> (module a racket
> (provide a%)
> (define a%
>(class object%
> (super-new)
> (define/public (mam a-b i)
>(displayln `(in a ,i))
>(when (> i 0)
> (send a-b mbm this (- i 1)))
>
> (module b racket
> (provide b%)
> (define b%
>(class object%
> (super-new)
> (define/public (mbm an-a i)
>(displayln `(in b ,i))
>(when (> i 0)
> (send an-a mam this (- i 1)))
>
> (module main racket
> (require (submod ".." a) (submod ".." b))
>
> (define a (new a%))
> (define b (new b%))
>
> (send a mam b 1))
>
> (require 'main)
>
>
>
With include I can do the following:
File: a-class.rkt
(define a-class
{class object%
(super-new)
(define/public (who what)
(cond ((is-a? what a-class) 'me)
((is-a? what b-class) 'not-me)))})
File: b-class .rkt
(define b-class
{class object%
(super-new)
(define a (new a-class))
(define/public (hello) 'hello-world)
(define/public (delegate-who what)
(send a who what)) })
File: c.rkt
(include (file "a-class.rkt"))
(include (file "b-class.rkt"))
Read Evaluate Print Loop:
(load "Desktop/c.rkt") ; or equivalent path
(define a (new a-class))
(s
Re: [racket-users] Simple Interdependent Units?
If you mean you want truly decoupled views and models, you'd end up in this position: #lang racket ;; decoupled model-view (module model racket (provide model%) (define model% (class object% (init-field view) (super-new) (define the-number 12) (define/public (setter v) (when (or (< v 0) (> 0 100)) (send view error "can't do that")) (set! the-number v)) (define/public (get) the-number (module view racket/gui (provide view%) (require (submod ".." model)) (define view% (class object% (init-field model) (define frame (new frame% [width 100][height 200][label "VW"])) (define vpane (new vertical-pane% [parent frame])) (define value0 (send model get)) (define slide (new slider% [parent vpane] [label "%"] [min-value 0] [init-value value0] [max-value 100] [style '(vertical)])) (define/public (error msg) (displayln msg)) (send frame show #t ;; - (require 'view 'model) (define the-view (new view% [model (new model% [view the-view])])) If you run this code and then call make-voew in the repl, you get an error about the use of the value the-view before its initialization. ;; So here is how you do it with units: #lang racket/gui (define-signature model^ (setter get)) (define-signature view^ (error)) ;; decoupled model-view (define model@ (unit (import view^) (export model^) ;; --- (define the-number 12) (define (setter v) (when (or (< v 0) (> 0 100)) (error "can't do that")) (displayln `(setting to ,v)) (set! the-number v)) (define (get) the-number))) (define view@ (unit (import model^) (export view^) (define frame (new frame% [width 100][height 200][label "VW"])) (define vpane (new vertical-pane% [parent frame])) (define value0 (get)) (define slide (new slider% [parent vpane] [label "%"] [min-value 0] [init-value value0] [max-value 100] [style '(vertical)] [callback (lambda (self _e) (setter (send self get-value)))])) (define (error msg) (displayln msg)) ;; run program run (send frame show #t))) (define completly-linked-program@ (compound-unit (import) (export) (link [((model : model^)) model@ view] (((view : view^)) view@ model (define (run) (invoke-unit completly-linked-program@)) ;; --- Now if you just want two modules with classes that can send message to each other, assuming that they get objects of the right kind, that's straightforward: #lang racket (module a racket (provide a%) (define a% (class object% (super-new) (define/public (mam a-b i) (displayln `(in a ,i)) (when (> i 0) (send a-b mbm this (- i 1))) (module b racket (provide b%) (define b% (class object% (super-new) (define/public (mbm an-a i) (displayln `(in b ,i)) (when (> i 0) (send an-a mam this (- i 1))) (module main racket (require (submod ".." a) (submod ".." b)) (define a (new a%)) (define b (new b%)) (send a mam b 1)) (require 'main) On May 25, 2015, at 11:58 AM, Michael Tiedtke wrote: > > Il giorno 25/mag/2015, alle ore 14.43, Jens Axel Søgaard ha scritto: > >> Hi Michael, >> >> It would be interesting to hear about the situation that led to a cyclic >> dependency. >> >> The few cases where I have had a problem I managed to solve it by moving >> all structure definitions into a separate module structs.rkt and then >> requiring >> that module everywhere else. >> >> /Jens Axel > > > It's in Open Flowers (on the mailing list and on planet). I wouldn't even > call it > cyclic dependency but interdependent classes. Elsewhere (I found two threads > about this subject on this mailing list) someone mentioned that the model-view > (as in model view controller) "paradigm" leads to interdependent classes. Some > call them framework which sustain themselves like a construction in euclidian > geometry ... > > Specifically the cornerstones of the table mechanic (where one can put > cards) are > interdependent. One thing that I could cut out and put into its own module in > its own > file was a simple flower dialog which works like a color chooser with a hard > coded > callback sending a message to its hosting object. Where, on the other hand, > I'm stuck > with copy&paste are the different layout classes but that might be due to my > unwillingness to abstract layouts any further. Or it had to do with the > problem of > creating a super class. Right now I can't remember ... > >
Re: [racket-users] Simple Interdependent Units?
Il giorno 25/mag/2015, alle ore 14.29, Matthias Felleisen ha scritto: > > On May 25, 2015, at 5:52 AM, Michael Tiedtke wrote: > >> As I had to find out Racket's module system doesn't support cyclic >> dependencies. In that case I should use units. But as far as I have >> understood the concept of full fledged units I must either write a lot of >> redundant code like signature auto^, implementation auto@, import auto^, >> require "auto.rkt", export auto^ etc >> OR I could create a lot of files following a certain naming conventions when >> using whole module units. Both approaches are more hassle than managing the >> respective files of my "framework" with copy&paste and via include. > > > The whole point of units is to avoid copy and paste. (Indeed, the entire > history of programming languages is abut avoiding copy and paste.) > > While I agree that units are syntactically somewhat more cumbersome, the > overhead is tolerable in my opinion. Then again as a co-conspirator of units, > you wouldn't expect me to say anything else. Well, right now I consider include to be superior for my little program. > > Warning: units have limited type support, and it's only being turned into > code for HEAD now. > > >> Isn't there any simple way to declare cyclic dependencies? > > > Most PLs don't have cyclic modules. (They may pretend to have modules but > don't, which is why cyclic linking works.) > > The normal way of dealing with cyclic dependencies is to cut the static ties > and replace them with dynamic ones, usually callbacks via lambdas and/or > overriding in classes. > Most implementations of an Algorithmic Language Scheme do have no problem with interdependent modules. Pretending to have modules and recreating inheritance with encapsulation are two distinct things. I'd say as long as they allow to seperate and reunite scopes with fine grained control they should be considered viable approaches to modules systems. Tying them to the file level might even be a good idea. Recreating header files reminds me of m4. Cutting static ties means to change the logic of my program because of typographic needs, i.e. the file is become too big. Honestly, I do that a lot of times but I don't see the reason why I shouldn't dispatch on type just to create a module out of my abstract class. The only reason why one needs modules is source code management and that mostly happens in combination with files. Then one needs hygiene in the top level environment to not go back to the LISP era - but other module systems allow me to do that. > > >> Can I put the signature and the implementation into one file? > > Yes. > > >> How do I require or import such an interdependent unit framework? Do I have >> to use invoke-unit or require or ...? > > > Let's call #lang-modules, compilation packages (CP) here. > > Units are run-time values. They are first-class, like numbers. They come with > a range of operations, like booleans. These include: creation, linking, and > invoking. You can also store them in containers. You can even print them: > > > (displayln (unit (import) (export))) > # > > As such a CP can provide and require units. You can also protect units with > contracts. > > Signatures are syntactic constructs. At run-time they are gone. The point of > CPs is that you can provide and require syntactic constructs, too. So yes, > you can provide and require signatures but it doesn't mean > providing/requiring them at run-time. They are dealt with at compile time. At > compile time, you can also manipulate signatures with operations such as > extending them. (Perhaps there's nothing else.) > Some self hosting environments one day might not even know about the distinction between compile time and run time anymore. As far as I remember the algorthmic language scheme was divided into to "stages": reader and interpreter. Interestingly enough Racket's module system doesn't handle interdependencies well while it's reader does have no problems with applying procedures which are defined only later on in the text. Other implementations can cope with interdependent modules but fail(ed) when you tried to use something before its definition. > ;; --- > > I recommend you make 3-line examples of signatures, units, linking > expressions (compounds) and invocations -- all in one CP. Then you may wish > to separate them into different CPs, without changing the syntax, just use > require/provide. Finally you may wish to use the special CP languages for > declaring signatures and units. And finally you want to play with inferred > linking. > > Holler when you get stuck -- Matthias > Yes, thanks again a lot. But for now I'm the lazy programmer stuck with include. -- 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+unsubs
Re: [racket-users] Simple Interdependent Units?
Il giorno 25/mag/2015, alle ore 14.43, Jens Axel Søgaard ha scritto: > Hi Michael, > > It would be interesting to hear about the situation that led to a cyclic > dependency. > > The few cases where I have had a problem I managed to solve it by moving > all structure definitions into a separate module structs.rkt and then > requiring > that module everywhere else. > > /Jens Axel It's in Open Flowers (on the mailing list and on planet). I wouldn't even call it cyclic dependency but interdependent classes. Elsewhere (I found two threads about this subject on this mailing list) someone mentioned that the model-view (as in model view controller) "paradigm" leads to interdependent classes. Some call them framework which sustain themselves like a construction in euclidian geometry ... Specifically the cornerstones of the table mechanic (where one can put cards) are interdependent. One thing that I could cut out and put into its own module in its own file was a simple flower dialog which works like a color chooser with a hard coded callback sending a message to its hosting object. Where, on the other hand, I'm stuck with copy&paste are the different layout classes but that might be due to my unwillingness to abstract layouts any further. Or it had to do with the problem of creating a super class. Right now I can't remember ... -- 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] Simple Interdependent Units?
Hi Michael, It would be interesting to hear about the situation that led to a cyclic dependency. The few cases where I have had a problem I managed to solve it by moving all structure definitions into a separate module structs.rkt and then requiring that module everywhere else. /Jens Axel 2015-05-25 11:52 GMT+02:00 Michael Tiedtke : > As I had to find out Racket's module system doesn't support cyclic > dependencies. In that case I should use units. But as far as I have > understood the concept of full fledged units I must either write a lot of > redundant code like *signature auto^*, *implementation auto@,* *import > auto^*, *require "auto.rkt",* *export auto^* etc > OR I could create a lot of files following a certain naming conventions > when using whole module units. Both approaches are more hassle than > managing the respective files of my "framework" with copy&paste and via > *include.* > > *Isn't there any simple way to declare cyclic dependencies?* > > Can I put the signature and the implementation into one file? > > How do I require or import such an interdependent unit framework? Do I > have to use invoke-unit or require or ...? > > -- > 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. > -- -- Jens Axel Søgaard -- 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] Simple Interdependent Units?
On May 25, 2015, at 5:52 AM, Michael Tiedtke wrote: > As I had to find out Racket's module system doesn't support cyclic > dependencies. In that case I should use units. But as far as I have > understood the concept of full fledged units I must either write a lot of > redundant code like signature auto^, implementation auto@, import auto^, > require "auto.rkt", export auto^ etc > OR I could create a lot of files following a certain naming conventions when > using whole module units. Both approaches are more hassle than managing the > respective files of my "framework" with copy&paste and via include. The whole point of units is to avoid copy and paste. (Indeed, the entire history of programming languages is abut avoiding copy and paste.) While I agree that units are syntactically somewhat more cumbersome, the overhead is tolerable in my opinion. Then again as a co-conspirator of units, you wouldn't expect me to say anything else. Warning: units have limited type support, and it's only being turned into code for HEAD now. > Isn't there any simple way to declare cyclic dependencies? Most PLs don't have cyclic modules. (They may pretend to have modules but don't, which is why cyclic linking works.) The normal way of dealing with cyclic dependencies is to cut the static ties and replace them with dynamic ones, usually callbacks via lambdas and/or overriding in classes. > Can I put the signature and the implementation into one file? Yes. > How do I require or import such an interdependent unit framework? Do I have > to use invoke-unit or require or ...? Let's call #lang-modules, compilation packages (CP) here. Units are run-time values. They are first-class, like numbers. They come with a range of operations, like booleans. These include: creation, linking, and invoking. You can also store them in containers. You can even print them: > (displayln (unit (import) (export))) # As such a CP can provide and require units. You can also protect units with contracts. Signatures are syntactic constructs. At run-time they are gone. The point of CPs is that you can provide and require syntactic constructs, too. So yes, you can provide and require signatures but it doesn't mean providing/requiring them at run-time. They are dealt with at compile time. At compile time, you can also manipulate signatures with operations such as extending them. (Perhaps there's nothing else.) ;; --- I recommend you make 3-line examples of signatures, units, linking expressions (compounds) and invocations -- all in one CP. Then you may wish to separate them into different CPs, without changing the syntax, just use require/provide. Finally you may wish to use the special CP languages for declaring signatures and units. And finally you want to play with inferred linking. Holler when you get stuck -- Matthias -- 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] Simple Interdependent Units?
As I had to find out Racket's module system doesn't support cyclic dependencies. In that case I should use units. But as far as I have understood the concept of full fledged units I must either write a lot of redundant code like signature auto^, implementation auto@, import auto^, require "auto.rkt", export auto^ etc OR I could create a lot of files following a certain naming conventions when using whole module units. Both approaches are more hassle than managing the respective files of my "framework" with copy&paste and via include. Isn't there any simple way to declare cyclic dependencies? Can I put the signature and the implementation into one file? How do I require or import such an interdependent unit framework? Do I have to use invoke-unit or require or ...? -- 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.
