nemesis wrote:
> good ol' abstract data types.

That's not an abstract data type. It's merely a hidden implementation.

>  I still enjoy Haskell's powerful algebraic
> datatypes, higher-order functions, currying and concise coding a lot more.

*That* is way closer to an abstract data type. :-)  And yah, I'm not 
condoning it as better. Merely as possible.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Orchid XP v7 wrote:
>  (But then, presumably the module that 
> uses this thing will handle all creation and destruction.)

Well, yes, that's the idea. That's one way it's better than C++'s 
mechanism, which requires you to (for example) recompile every client if 
you change the layout of the private bits of the class.

> Also fun, you 
> how cannot have an array of this thing.

You can't have an array of pointers, or an array of the things? That 
seems odd if the former.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New wrote:
> Orchid XP v7 wrote:
>>  (But then, presumably the module that uses this thing will handle all 
>> creation and destruction.)
> 
> Well, yes, that's the idea. That's one way it's better than C++'s 
> mechanism, which requires you to (for example) recompile every client if 
> you change the layout of the private bits of the class.
> 
>> Also fun, you how cannot have an array of this thing.
> 
> You can't have an array of pointers, or an array of the things? That 
> seems odd if the former.

No, the latter; you can't have an array who's elements are a particular 
type since the compiler won't know how big it is.

(Notice that Haskell has no such limitation; you can expose no 
implementation information to THE PROGRAMMER whilst this information IS 
still exposed to THE COMPILER. Indeed, you can even define rewrite rules 
on the code in your library, so clients of the library actually have 
their code transparently rewritten, and the clients don't need to know 
this...)

Post a reply to this message

Invisible wrote:
> No, the latter; you can't have an array who's elements are a particular 
> type since the compiler won't know how big it is.

Right. Not unusual in compiled languages, that.

> (Notice that Haskell has no such limitation; you can expose no 
> implementation information to THE PROGRAMMER whilst this information IS 
> still exposed to THE COMPILER. 

So, I can have a module that changes the size of the objects it works 
with, and the compiled code of the caller doesn't have to see that?

I.e., to make this happen, does the caller need the source code to my 
module? Or can I compile that module, give you the executable (or 
library), and you can allocate the right size object without knowing it?

Cause, like, doing that when you're distributing library sources is 
pretty easy.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> No, the latter; you can't have an array who's elements are a 
>> particular type since the compiler won't know how big it is.
> 
> Right. Not unusual in compiled languages, that.

Indeed.

>> (Notice that Haskell has no such limitation; you can expose no 
>> implementation information to THE PROGRAMMER whilst this information 
>> IS still exposed to THE COMPILER. 
> 
> So, I can have a module that changes the size of the objects it works 
> with, and the compiled code of the caller doesn't have to see that?

No.

If your code calls my module, and my module changes internally, you will 
have to recompile your code. You don't need to *change* your source code 
in any way, just recompile it.

The optimiser performs moderately extensive cross-module optimisations.

[My code might get inlined into yours. My types (which you, the 
programmer, can't see the representation for) might get unboxed into CPU 
registers during tight inner loops in your code. My module might define 
transformation rules that rewrite parts of your program when you compile 
it. And you don't have to care about any of this...]

> I.e., to make this happen, does the caller need the source code to my 
> module? Or can I compile that module, give you the executable (or 
> library), and you can allocate the right size object without knowing it?

Suppose I write some module named "Banana". In order to compile your 
code against my module, you will need to possess either

* The source code ("Banana.hs")

* The object code ("Banana.o") + the interface file ("Banana.hi")

As long as you have one or the other, you can compile against my code. 
So yes, I can write Banana.hs, compile it (thus generating Banana.o and 
Banana.hi) and give you the latter files (which are both binary). You 
won't have my source code, but you can still compile against it.

Indeed, the compiler ships with compiled base libraries, and doesn't 
*provide* source code unless you download it seperately. (Which is just 
as well, because it's quite large and takes a while to compile...)

(As an aside, in order to use the object code file, you'll need to be 
using the exact same compiler version as me. On the same platform, 
obviously.)

> Cause, like, doing that when you're distributing library sources is 
> pretty easy.

Um... I'm not sure exactly which statement you're trying to make.

Post a reply to this message

Invisible wrote:
>> Right. Not unusual in compiled languages, that.
> Indeed.

OK, all the stuff you described is pretty much SOP for compiled modular 
languages (for everything but C++, that is).

Ada, for example, won't even let you link against the .o file if you 
compiled against a corresponding .hi file that was compiled more 
recently than the .o file.  So you can't even mix-and-match 
representations incorrectly.

> Um... I'm not sure exactly which statement you're trying to make.

I meant that making it such that you can "hide" the representation from 
the programmer and do all that fancy stuff, but then require the source 
files of the declarations (a la C++) is a pretty easy thing to do. Much 
harder to allow (say) inlining of already-compiled code.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

> Invisible wrote:
>>> Right. Not unusual in compiled languages, that.
>> Indeed.
> 
> OK, all the stuff you described is pretty much SOP for compiled modular 
> languages (for everything but C++, that is).
> 
> Ada, for example, won't even let you link against the .o file if you 
> compiled against a corresponding .hi file that was compiled more 
> recently than the .o file.  So you can't even mix-and-match 
> representations incorrectly.
> 
>> Um... I'm not sure exactly which statement you're trying to make.
> 
> I meant that making it such that you can "hide" the representation from 
> the programmer and do all that fancy stuff, but then require the source 
> files of the declarations (a la C++) is a pretty easy thing to do. Much 
> harder to allow (say) inlining of already-compiled code.
> 

I'm probably missing something... can't you do it with .o + .h in C++?

Post a reply to this message

Nicolas Alvarez wrote:
> I'm probably missing something... can't you do it with .o + .h in C++?

The .h file is source code, hence revealing the internal layout of your 
objects. And the functions you want to inline are presented in source. 
And you can't be sure the .h matches the .o.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New wrote:
> Nicolas Alvarez wrote:
>> I'm probably missing something... can't you do it with .o + .h in C++?
> 
> The .h file is source code, hence revealing the internal layout of your 
> objects. And the functions you want to inline are presented in source. 
> And you can't be sure the .h matches the .o.

...whereas Haskell's .hi files are machine-generated (and not 
human-readable).

Post a reply to this message

On Thu, 01 Nov 2007 21:13:15 +0000, Orchid XP v7 wrote:
> I was under the impression that these encodings apply to *strings*, not 
> individual characters by themselves...

The encoding applies to individual characters, and
from those characters is the string composed.



  code point character   utf8 encoding
   U+006B     k            6B


   U+0070     p            70
   U+0069     i            69


So the UTF-8 encoding of the string becomes 9 bytes long in total.

Similarly, the Czech word for "cat" would be encoded like this:

  code point character   utf8 encoding
   U+006B     k            6B
   U+006F     o            6F
   U+010D     ?            C4 8D
   U+006B     k            6B
   U+0061     a            61

(Note: I'm posting in iso-8859-1, which cannot express
the third character in the word: a "c" with a hacek,
hence substituting with "?".)

And the Japanese word for Japan would be:

  code point character   utf8 encoding
   U+65E5     ?            E6 97 A5
   U+672C     ?            E6 9C AC 

The encoding (UTF-8) has a few clever attained design goals:
- Backwards compatibility with ASCII
- Asciibetical sorting still works the same way
- Forward and backward seeking in the string possible without desynchronization
- Minimal space wasted
- Possibility to extend naturally if the unicode set grows

-- 
Joel Yliluoma - http://iki.fi/bisqwit/

Post a reply to this message