[bitc-dev] Opinions wanted: Infix shift operators
Elias Gabriel Amaral da Silva
tolkiendili at gmail.com
Thu Aug 5 00:07:06 PDT 2010
2010/7/28 Jonathan S. Shapiro <shap at eros-os.org>:
> On Tue, Jul 27, 2010 at 5:12 PM, Nathaniel W Filardo <nwf at cs.jhu.edu> wrote:
>>
>> If I read this correctly, then BitC's syntax is such that the lexemes >>
>> and
>> << are only sensible inside expression context. If there are
>> lexical-level
>> entities which would signal transitions from type context to expression
>> context and back, then it would also suffice to use those cues to switch
>> syntax tables....
>
> That could be done, but I think it's not a good idea to do it in BitC. Three
> reasons:
>
> 1. Expression and type context are commingled where dependent types exist
> 2. In some cases, 1 token lookahead is required for context
> disambiguation.
> If tokenization is context-dependent, that's not so happy-making.
> 3. If we ever want to show the correctness of a parser, switching the
> syntax
> dynamically is a Bad Thing(tm).
>
>>
>> > I've been planning to take advantage of this to overload them for I/O in
>> > the
>> > same way that C++ does. This means that you can write:
>> >
>> > stdout >> e1 >> e2
>>
>> > Normally, << and >> are only done with an integer-ish type on the right.
>> Please don't do this, regardless of how you solve the syntactic problem
>> above.
>
> The problem at heart is that BitC doesn't have variadic procedures, and
> therefore cannot implement printf(). My intention above was to propose a
> typable mechanism for stream "forwarding" where multiple objects are to be
> emitted. From our phone call, your concern is less about this syntax than
> about the horrible state conflation in the C++ IOStreams model (e.g.
> std::hex). I agree with you about that concern, but that's simply a case of
> a badly designed interface; it has little to do with this choice of syntax.
> Just as one possible alternative, replace C++:
You probably know about ocaml and haskell hacks to implement printf.
Don't you like it? OCaml's, is particularly interesting, because it
doesn't involve run-time checking of the types (with a small penalty
of having to define the format string statically)
I mean, strictly speaking, ocaml doesn't have variadic functions
either, but instead parametrizes the type of the printing function
using the format string (printf has a type like 'a format -> 'a). So
printf "%d" is a int -> unit function, because "%d" has type (int ->
unit) format. (the actual type is more complicated, to accomodate
sprintf, etc)
It has the oddity of not actually accepting strings, but something
that is lexically identical but resolved as a "format string" instead.
But as long as you define another lexical convention for format
strings, it's actually very clean..
--
Elias Gabriel Amaral da Silva <tolkiendili at gmail.com>
More information about the bitc-dev
mailing list