Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: cr@dcs.ed.ac.uk
To: Michel.Mauny@inria.fr
Cc: caml-list@margaux
Subject: Stream patterne matching
Date: Mon, 15 Mar 93 20:45:23 GMT	[thread overview]
Message-ID: <26877.9303152045@damsay.dcs.ed.ac.uk> (raw)
In-Reply-To: Michel Mauny's message of Mon, 15 Mar 1993 20:12:13 +0100 (MET) <9303151912.AA10634@pauillac.inria.fr>


J'ecris, puis Michel repond :

> > Pour quelles raisons le pattern matching sur les streams est-t'il
> > destructif ?  
> >
> > Est-ce simplement une question de performance. Si oui il faut que le gain
> > soit important. En effet, le pattern matching destructif implique un effet
> > de bord implicite. Je trouverais plus propre d'avoir a utiliser soi-meme un
> > pointeur lorsque-l'on veux simuler le pattern matching destructif.
>
> Non, ce n'est pas simplement une question de performance: un autre
> avantage est d'e^tre bien adapte' aux entre'es-sorties destructives de
> ML. Un stream se manipule un peu comme un canal d'entre'e (type
> in_channel): lorsqu'on lit un caracte`re sur un canal (resp. stream),
> une seconde lecture lit le caracte`re suivant.
>
> Avec une semantique destructive du filtrage de streams, un stream
> construit a` partir de std_in aura le me^me comportement qu'un autre
> stream (construit par programme). Avec une se'mantique
> non-destructive du filtrage, cela n'est possible que si ce stream
> garde en me'moire le stream d'entre'e en entier (a` moins de garantir
> qu'il n'existe pas de pointeur vers ce stream).

N'est-ce pas au GC de recuperer l'espace occupe par le debut d'un stream, s'il
n'y a plus de pointeur dessus ?

A t'on deja chiffrer la perte en performance, si l'on n'utilise que des
streams conservateurs ?

--------------------

Un autre petit probleme avec le pattern matching : le fait qu'il soit
predictif (c.a.d. qu'il decide uniquement sur le premier element du stream).

Cela n'est pas grave : si l'on veut matcher [< '0 ; '1>] ou [< '0 ; '2 >], 
on ecrit [< '0 ; f c >] ou f match [< '1 >] ou [< '2 >]. 

Est-ce que le compilateur ne pourrait pas faire cela automatiquement ?

C'est a dire faire cette decomposition des qu'un certain nombre de patterns
consecutifs commencent par une suite de patterns egaux (au noms des variables
pres) ?

Cela simplifierait l'ecriture de la plupart des grammaires courantes. Tout en
sachant bien que la semantique est la meme. 


Christophe





  reply	other threads:[~1993-03-16  8:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-03-15 14:11 cr
1993-03-15 19:12 ` Michel Mauny
1993-03-15 20:45   ` cr [this message]
1993-03-16  3:09 Daniel de Rauglaudre
     [not found] <9303171031.AA15612@pauillac.inria.fr>
1993-03-17 11:31 ` cr
1993-03-17 13:47   ` Michel Mauny
1993-03-17 18:06     ` murthy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26877.9303152045@damsay.dcs.ed.ac.uk \
    --to=cr@dcs.ed.ac.uk \
    --cc=Michel.Mauny@inria.fr \
    --cc=caml-list@margaux \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox