ooc-dev team mailing list archive

[Amos Wenger <amoswenger@xxxxxxxxx>]

Hmm I'm not sure about enforcing this from within the compiler. I'm not sure
how to do it either (by which rules - only allowed for extern functions?)

ndd

On Sat, Aug 7, 2010 at 7:33 PM, Marc Calaway
<walker_tejas_ranger@xxxxxxxx>wrote:

> Of course it'd be a chance to clean up code. But I don't see any reason why
> to allow it for everyday, pure ooc-code.
> That's what I mean by "FFI". It should be restricted to a very small part
> of the language. Automatic translation in larger projects... I better
> prepare my pipe bombs.
>
> "It's not a feature, it's a bug!"
>
> --- Amos Wenger <amoswenger@xxxxxxxxx> schrieb am Sa, 7.8.2010:
>
> Von: Amos Wenger <amoswenger@xxxxxxxxx>
> Betreff: Re: [Ooc-dev] [ooc-dev] "Implicit As"
> An: "Marc Calaway" <walker_tejas_ranger@xxxxxxxx>
> CC: ooc-dev@xxxxxxxxxxxxxxxxxxx
> Datum: Samstag, 7. August, 2010 17:12 Uhr
>
> Hey there, good to finally have you on the mailing list there
> So the 'translation' (e.g. replacing s by s data) doesn't seem too bad to
> me. In fact, that's how I had planned to implement it in the beginning.
>
>
> And by FFI I'm not exactly sure what you mean. Do you want to create
> 'wrapper' for C functions, ie. if it takes a 'char*' there's a variant that
> can also take a String? That sounds a lot messier than the 'translation'
> alternative imho. And generates more code, too.
>
>
> The main use of "implicit as" I currently see is precisely this char* vs
> String matter. But in the future it might be useful with other bindings.
> If it is used irresponsibly by users it might lead to a mess. But what are
> the alternatives? Manually converting types / calling conversion functions,
> etc.? Don't think so.
>
>
> With every feature we give to users, we give them a chance to mess up - but
> also an opportunity to write cleaner code. When well used, implicit as is
> very useful imho.
> In the docs, we might add this piece of advice: "'implicit as' is designed
> as a facility for interfacing with foreign code. It's probably a wrong
> solution for many other problems."
>
>
> ndd
> On Sat, Aug 7, 2010 at 6:41 PM, Marc Calaway <walker_tejas_ranger@xxxxxxxx>
> wrote:
>
>
> Hey there,
>
>
>
> I'd like to suggest some possibilities to the so-called "implicit-as".
> Background is the migration to a String-class from plain `Char*`.
>
> However, since C is our core backend language, interoperability is an
> important factor.
>
> rofl0r wanted to have an automatic translation when one passes a
> String-class object to an external C function
>
> expecting a Char*.
>
> (The actual implementation of String is not important right now.)
>
>
>
> In code (ooc):
>
>   String: class {size: SizeT; data: Char*} // or whatever
>
>   a := "hello, world" // Of type "String"
>
>   puts: extern func(Char*)
>
>   puts(a)
>
>
>
> What's the matter? Well, String won't be a 'Cover' anymore, so one can't
> pass a String when a Char*'s expected.
>
>
>
> The translation process itself would consist of a simple replacement:
>
>   puts(a)
>
> becomes
>
>   puts(a data)
>
>
>
> As you can see, the user would not have to do this manually.
>
> Issue's now how to achieve this goal. First, there was the idea to do it as
> an operator.
>
>   operator implicit as (s: String) -> Char* { s data }
>
>
>
> Well, that doesn't make much sense. It's not an action where a operator
> takes place. In fact, you can't see it at all, it'd be invisible.
>
> In my opinion, an operator is always some sort of literal as in "+, -, ++,
> ..."
>
>
>
> Another alternative would be the introduction of a new keyword, e.g.
> "otherwise" (don't get me on the naming).
>
>   String: class { size: SizeT; otherwise data : Char* } // more pseudo
> code, yes...
>
>
>
> The problem right here is to figure out when to fall back to the
> "otherwise"-case.
>
> "Just when an extern function expects a Char*" you might think. But that's
> a special case then. We'd introduce new syntax pollution for a very special
> case. That's wasted grammar, it needs to be more general.
>
>
>
>
>
> There has to be a way to clearly say on which context a translation should
> take place.
>
>   String: class { size: SizeT; data: Char*; context { String: this; Char*:
> data }}
>
>
>
> (Yes, context is a very bad keyword, it's just used for this presentation.)
>
> Harhar, now let's destroy this one.
>
> First, it works around rock's type-system. Kay, we often do in rock itself,
> but never in user-code.
>
> Q: Why this?
>
> A: Simply because the `context` section is not translated to C. It's not
> checked during runtime but all handled
>
> during the process of compilation. It's an annotation.
>
>
>
> By itself, not a too bad idea, but it makes the language and larger sources
> a lot more difficult to understand.
>
> "Yay, we're passing an object of type A to a function which expects a... oh
> wtf - it wants to have type Z"
>
> You can imagine the rest, and some very clever people already wrote a lot
> about this case. They called that source of evil C++.
>
>
>
> Automatic transformation into another type is a ***very***,
> ******very******* sharp sword. Too dangerous to be given
>
> to the user.
>
> "But didn't you say the "implicit-as" has to be general?" Yep, I did. And
> I'm coming to the conclusion that this not
>
> completely right. FFI is the magic word. We don't need the transformation
> in pure ooc-code but just when interfacing
>
> foreign code.
>
> My suggestion is to introduce some sort of API which handles these cases -
> just for cases when interfacing with C.
>
> It'd be done as a way of compiler annotation.
>
>
>
> I don't give any source here because I have no idea what's the best way to
> do this. That's why I'm asking YOU, (yes I'm lookign right at you)
>
> to put your opinion on the ML.
>
>
>
> Does "implicit-as" makes sense at all?
>
> Should it be used in everyday ooc?
>
> Are annotation the right way to do this?
>
> Do we need a special FFI to C?
>
>
>
> BTW: This is not my work alone, I tried to summarize rofl0r's main idea and
> added suggestions on how to achieve it.
>
>
>
> Cheers,
>
>
>
> Yannic (showstopper)
>
>
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev
> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev
> More help   : https://help.launchpad.net/ListHelp
>