Mostra notizie nelle discussioni
  • Avatar
    ☺
    Scritto da
    altg
    utente che non utiene
    il 2014-10-28 15:59:04.0 alle 2014-10-28 15:59:04.0
    Trollate totali: 11540
    umm... non sono sicuro ma tendenzialmente anche forse
    Ho cercato di classificare formalmente le "inlet" in L.in.oleum 4. La premessa e` che il termine "inlet" e` un catch-all, significa essenzialmente subroutine: una label di codice che puo` essere chiamata. Poi le inlets possono essere, a seconda di come vengono dichiarate e di come si comportano, ricondotte ai casi di subroutine semplici, funzioni, o metodi. I termini che ho definito per dichiararle (e su cui il compilatore effettua dei controlli per produrre avvisi quando qualcosa non e` chiamato in un modo compatibile con la sua dichiarazione) sono questi:

    [monaural | binaural] [fn | id]
    


    Il che significa che la inlet puo` essere dichiarata opzionalmente o monaural o binaural, e come ulteriore opzione, o funzione generica (fn) o funzione identita` (id). "monaural" e "binaural" si occupano della questione di come vengono legate all'istanza su cui operano: la sintassi monaural ("che sente da un solo orecchio") e` quella tipica in cui si lega l'istanza alla chiamata, tipo "antani.stampa(perTerra)"; la sintassi binaural (che sente da due orecchie) e` compatibile con la monaural ma in piu` permette di specificare l'istanza come argomento, cioe` di scrivere ANCHE in forma imperativa "stampa(antani,perTerra)". Ci sono delle differenze tra efficienza e comodita` tra le due, a seconda delle circostanze, sicche` non e` affatto privo di senso dichiarare, generalmente come sinonimo, la forma binaural (perche` se l'istanza viene passata come argomento e il metodo non e` una funzione, il registro di riserva diventa caller-saved). Per quanto riguarda le identita`, si dichiarano per usare le fluent interfaces, quelle dove un metodo e` una funzione che ritorna sempre l'istanza su cui opera (dove poi metti le chiamate "a trenino").

    Per tornare torna, e permette di delineare piuttosto bene il comportamento di una inlet. Temo solo che non ci si capisca un cazzo. Avro` mica ragione? Anonimo
    • Avatar
      Scritto da
      Non Autenticato
      il 2014-10-28 17:19:44.0 alle 2014-10-28 17:19:44.0
      Re: umm... non sono sicuro ma tendenzialmente anche forse
      Scritto da: altg
      > Ho cercato di classificare formalmente le "inlet" in L.in.oleum 4. La premessa e` che il termine "inlet" e` un catch-all, significa essenzialmente subroutine: una label di codice che puo` essere chiamata. Poi le inlets possono essere, a seconda di come vengono dichiarate e di come si comportano, ricondotte ai casi di subroutine semplici, funzioni, o metodi. I termini che ho definito per dichiararle (e su cui il compilatore effettua dei controlli per produrre avvisi quando qualcosa non e` chiamato in un modo compatibile con la sua dichiarazione) sono questi:
      >
      >
      > [monaural | binaural] [fn | id]
      > 

      >
      > Il che significa che la inlet puo` essere dichiarata opzionalmente o monaural o binaural, e come ulteriore opzione, o funzione generica (fn) o funzione identita` (id). "monaural" e "binaural" si occupano della questione di come vengono legate all'istanza su cui operano: la sintassi monaural ("che sente da un solo orecchio") e` quella tipica in cui si lega l'istanza alla chiamata, tipo "antani.stampa(perTerra)"; la sintassi binaural (che sente da due orecchie) e` compatibile con la monaural ma in piu` permette di specificare l'istanza come argomento, cioe` di scrivere ANCHE in forma imperativa "stampa(antani,perTerra)". Ci sono delle differenze tra efficienza e comodita` tra le due, a seconda delle circostanze, sicche` non e` affatto privo di senso dichiarare, generalmente come sinonimo, la forma binaural (perche` se l'istanza viene passata come argomento e il metodo non e` una funzione, il registro di riserva diventa caller-saved). Per quanto riguarda le identita`, si dichiarano per usare le fluent interfaces, quelle dove un metodo e` una funzione che ritorna sempre l'istanza su cui opera (dove poi metti le chiamate "a trenino").
      >
      > Per tornare torna, e permette di delineare piuttosto bene il comportamento di una inlet. Temo solo che non ci si capisca un cazzo. Avro` mica ragione? Anonimo

      Ma chi deve passare a questa da una versione precedente diventa pazzo, stai cambiando tutto! Deluso
      • Avatar
        ☺
        Scritto da
        altg
        utente che non utiene
        il 2014-10-28 17:47:22.0 alle 2014-10-28 17:47:22.0
        Trollate totali: 11540
        Re: umm... non sono sicuro ma tendenzialmente anche forse
        > > Ho cercato di classificare formalmente le "inlet" in L.in.oleum 4. La premessa e` che il termine "inlet" e` un catch-all, significa essenzialmente subroutine: una label di codice che puo` essere chiamata. Poi le inlets possono essere, a seconda di come vengono dichiarate e di come si comportano, ricondotte ai casi di subroutine semplici, funzioni, o metodi. I termini che ho definito per dichiararle (e su cui il compilatore effettua dei controlli per produrre avvisi quando qualcosa non e` chiamato in un modo compatibile con la sua dichiarazione) sono questi:
        > >
        > >
        > > [monaural | binaural] [fn | id]
        > > 

        > >
        > > Il che significa che la inlet puo` essere dichiarata opzionalmente o monaural o binaural, e come ulteriore opzione, o funzione generica (fn) o funzione identita` (id). "monaural" e "binaural" si occupano della questione di come vengono legate all'istanza su cui operano: la sintassi monaural ("che sente da un solo orecchio") e` quella tipica in cui si lega l'istanza alla chiamata, tipo "antani.stampa(perTerra)"; la sintassi binaural (che sente da due orecchie) e` compatibile con la monaural ma in piu` permette di specificare l'istanza come argomento, cioe` di scrivere ANCHE in forma imperativa "stampa(antani,perTerra)". Ci sono delle differenze tra efficienza e comodita` tra le due, a seconda delle circostanze, sicche` non e` affatto privo di senso dichiarare, generalmente come sinonimo, la forma binaural (perche` se l'istanza viene passata come argomento e il metodo non e` una funzione, il registro di riserva diventa caller-saved). Per quanto riguarda le identita`, si dichiarano per usare le fluent interfaces, quelle dove un metodo e` una funzione che ritorna sempre l'istanza su cui opera (dove poi metti le chiamate "a trenino").
        > >
        > > Per tornare torna, e permette di delineare piuttosto bene il comportamento di una inlet. Temo solo che non ci si capisca un cazzo. Avro` mica ragione? Anonimo
        >
        > Ma chi deve passare a questa da una versione precedente diventa pazzo, stai cambiando tutto! Deluso

        Temo che un po' traumatico sara`, si`. Triste
        Pero` che ti devo dire?
        Ho girato e rigirato la frittata finche` non e` venuta meglio.
        Ah comunque e` facile ricondurre, nelle spiegazioni, il discorso sopra al modo di classificare le funzioni nel "resto del mondo". In pratica:

        una dichiarazione senza "firme" significa subroutine: stampa (antani)
        una inlet "monaural" significa metodo: antani.stampa ()
        una inlet "fn" significa funzione: risultato = somma (x, y)
        una "monaural fn" e` un metodo che e` una funzione: l = blah.length()
        una "monaural id" e` un metodo in fluent interface: p = blah.length().alloc()

        basta rimandare a wikipedia per invitare a capire cos'e` un metodo, cos'e` una fluent interface, eccetera, e MAGARI diventa comprensibile, no? Geek

        No eh? Fantasma

        p.s. e non ho neanche accennato ai decoratori:

        frequent, framed, internal, rc

        frequent = chiamata frequente, allineata a una boundary di codice ottimale,
        framed = che ha uno stack frame,
        internal = privata (il compilatore avvisa se si chiama dall'esterno),
        rc = resource-collected (incorniciata da specifici prequel e sequel).

        I prequel e i sequel sono macro, infatti il compilatore v4 supporta le macro, e il decoratore "rc", per attivare la garbage collection a partire dal ramo dell'inlet dichiarata, non ha nulla di "hard-wired" nel compilatore: viene definito dalla libreria rc, il che permette di riscrivere come si comporta il collector.

        **Modificato dall'autore il 28.10.2014 17:54**
        • Avatar
          Scritto da
          Non Autenticato
          il 2014-10-28 19:15:52.0 alle 2014-10-28 19:15:52.0
          Re: umm... non sono sicuro ma tendenzialmente anche forse
          Scritto da: altg
          > > > Ho cercato di classificare formalmente le "inlet" in L.in.oleum 4. La premessa e` che il termine "inlet" e` un catch-all, significa essenzialmente subroutine: una label di codice che puo` essere chiamata. Poi le inlets possono essere, a seconda di come vengono dichiarate e di come si comportano, ricondotte ai casi di subroutine semplici, funzioni, o metodi. I termini che ho definito per dichiararle (e su cui il compilatore effettua dei controlli per produrre avvisi quando qualcosa non e` chiamato in un modo compatibile con la sua dichiarazione) sono questi:
          > > >
          > > >
          > > > [monaural | binaural] [fn | id]
          > > > 

          > > >
          > > > Il che significa che la inlet puo` essere dichiarata opzionalmente o monaural o binaural, e come ulteriore opzione, o funzione generica (fn) o funzione identita` (id). "monaural" e "binaural" si occupano della questione di come vengono legate all'istanza su cui operano: la sintassi monaural ("che sente da un solo orecchio") e` quella tipica in cui si lega l'istanza alla chiamata, tipo "antani.stampa(perTerra)"; la sintassi binaural (che sente da due orecchie) e` compatibile con la monaural ma in piu` permette di specificare l'istanza come argomento, cioe` di scrivere ANCHE in forma imperativa "stampa(antani,perTerra)". Ci sono delle differenze tra efficienza e comodita` tra le due, a seconda delle circostanze, sicche` non e` affatto privo di senso dichiarare, generalmente come sinonimo, la forma binaural (perche` se l'istanza viene passata come argomento e il metodo non e` una funzione, il registro di riserva diventa caller-saved). Per quanto riguarda le identita`, si dichiarano per usare le fluent interfaces, quelle dove un metodo e` una funzione che ritorna sempre l'istanza su cui opera (dove poi metti le chiamate "a trenino").
          > > >
          > > > Per tornare torna, e permette di delineare piuttosto bene il comportamento di una inlet. Temo solo che non ci si capisca un cazzo. Avro` mica ragione? Anonimo
          > >
          > > Ma chi deve passare a questa da una versione precedente diventa pazzo, stai cambiando tutto! Deluso
          >
          > Temo che un po' traumatico sara`, si`. Triste
          > Pero` che ti devo dire?
          > Ho girato e rigirato la frittata finche` non e` venuta meglio.
          > Ah comunque e` facile ricondurre, nelle spiegazioni, il discorso sopra al modo di classificare le funzioni nel "resto del mondo". In pratica:
          >
          > una dichiarazione senza "firme" significa subroutine: stampa (antani)
          > una inlet "monaural" significa metodo: antani.stampa ()
          > una inlet "fn" significa funzione: risultato = somma (x, y)
          > una "monaural fn" e` un metodo che e` una funzione: l = blah.length()
          > una "monaural id" e` un metodo in fluent interface: p = blah.length().alloc()
          >
          > basta rimandare a wikipedia per invitare a capire cos'e` un metodo, cos'e` una fluent interface, eccetera, e MAGARI diventa comprensibile, no? Geek
          >
          > No eh? Fantasma
          >
          > p.s. e non ho neanche accennato ai decoratori:
          >
          > frequent, framed, internal, rc
          >
          > frequent = chiamata frequente, allineata a una boundary di codice ottimale,
          > framed = che ha uno stack frame,
          > internal = privata (il compilatore avvisa se si chiama dall'esterno),
          > rc = resource-collected (incorniciata da specifici prequel e sequel).
          >
          > I prequel e i sequel sono macro, infatti il compilatore v4 supporta le macro, e il decoratore "rc", per attivare la garbage collection a partire dal ramo dell'inlet dichiarata, non ha nulla di "hard-wired" nel compilatore: viene definito dalla libreria rc, il che permette di riscrivere come si comporta il collector.

          Non sarebbe il caso di dargli una semplificata e far uscire direttamente Linoleum 4.4?
          • Avatar
            ☺
            Scritto da
            altg
            utente che non utiene
            il 2014-10-28 22:46:39.0 alle 2014-10-28 22:46:39.0
            Trollate totali: 11540
            Re: umm... non sono sicuro ma tendenzialmente anche forse
            > > > > Ho cercato di classificare formalmente le "inlet" in L.in.oleum 4. La premessa e` che il termine "inlet" e` un catch-all, significa essenzialmente subroutine: una label di codice che puo` essere chiamata. Poi le inlets possono essere, a seconda di come vengono dichiarate e di come si comportano, ricondotte ai casi di subroutine semplici, funzioni, o metodi. I termini che ho definito per dichiararle (e su cui il compilatore effettua dei controlli per produrre avvisi quando qualcosa non e` chiamato in un modo compatibile con la sua dichiarazione) sono questi:
            > > > >
            > > > >
            > > > > [monaural | binaural] [fn | id]
            > > > > 

            > > > >
            > > > > Il che significa che la inlet puo` essere dichiarata opzionalmente o monaural o binaural, e come ulteriore opzione, o funzione generica (fn) o funzione identita` (id). "monaural" e "binaural" si occupano della questione di come vengono legate all'istanza su cui operano: la sintassi monaural ("che sente da un solo orecchio") e` quella tipica in cui si lega l'istanza alla chiamata, tipo "antani.stampa(perTerra)"; la sintassi binaural (che sente da due orecchie) e` compatibile con la monaural ma in piu` permette di specificare l'istanza come argomento, cioe` di scrivere ANCHE in forma imperativa "stampa(antani,perTerra)". Ci sono delle differenze tra efficienza e comodita` tra le due, a seconda delle circostanze, sicche` non e` affatto privo di senso dichiarare, generalmente come sinonimo, la forma binaural (perche` se l'istanza viene passata come argomento e il metodo non e` una funzione, il registro di riserva diventa caller-saved). Per quanto riguarda le identita`, si dichiarano per usare le fluent interfaces, quelle dove un metodo e` una funzione che ritorna sempre l'istanza su cui opera (dove poi metti le chiamate "a trenino").
            > > > >
            > > > > Per tornare torna, e permette di delineare piuttosto bene il comportamento di una inlet. Temo solo che non ci si capisca un cazzo. Avro` mica ragione? Anonimo
            > > >
            > > > Ma chi deve passare a questa da una versione precedente diventa pazzo, stai cambiando tutto! Deluso
            > >
            > > Temo che un po' traumatico sara`, si`. Triste
            > > Pero` che ti devo dire?
            > > Ho girato e rigirato la frittata finche` non e` venuta meglio.
            > > Ah comunque e` facile ricondurre, nelle spiegazioni, il discorso sopra al modo di classificare le funzioni nel "resto del mondo". In pratica:
            > >
            > > una dichiarazione senza "firme" significa subroutine: stampa (antani)
            > > una inlet "monaural" significa metodo: antani.stampa ()
            > > una inlet "fn" significa funzione: risultato = somma (x, y)
            > > una "monaural fn" e` un metodo che e` una funzione: l = blah.length()
            > > una "monaural id" e` un metodo in fluent interface: p = blah.length().alloc()
            > >
            > > basta rimandare a wikipedia per invitare a capire cos'e` un metodo, cos'e` una fluent interface, eccetera, e MAGARI diventa comprensibile, no? Geek
            > >
            > > No eh? Fantasma
            > >
            > > p.s. e non ho neanche accennato ai decoratori:
            > >
            > > frequent, framed, internal, rc
            > >
            > > frequent = chiamata frequente, allineata a una boundary di codice ottimale,
            > > framed = che ha uno stack frame,
            > > internal = privata (il compilatore avvisa se si chiama dall'esterno),
            > > rc = resource-collected (incorniciata da specifici prequel e sequel).
            > >
            > > I prequel e i sequel sono macro, infatti il compilatore v4 supporta le macro, e il decoratore "rc", per attivare la garbage collection a partire dal ramo dell'inlet dichiarata, non ha nulla di "hard-wired" nel compilatore: viene definito dalla libreria rc, il che permette di riscrivere come si comporta il collector.
            >
            > Non sarebbe il caso di dargli una semplificata e far uscire direttamente Linoleum 4.4?

            Non so quanto si possa semplificare: non nego che non sia facile raccapezzarcisi, o almeno che la learning curve sia un pochettino ripida, pero` e` anche vero che le complicazioni emergono dal voler dare un certo grado di controllo al programmatore, a partire dal register naming, cioe` dalla scelta dei registri della CPU da usare. In altre parole, ok, sto gia` facendo il possibile per renderlo piu` espressivo, ma insomma non arrivera` mai al livello di un Quick Basic o di un Javascript. E` assembly: cross-platform, strutturato e oggettizzato ma fondamentalmente sempre assembly. Come minchia faccio a semplificare piu` di tanto l'assembly? A bocca aperta
<softv>

Pagina generata in 107 millisecondi

Utenti attivi: 7 nell'ultimo minuto, 22 negli ultimi cinque minuti, 40 negli ultimi 15 minuti