logs archiveBotHelp.net / Freenode / #ada / 2015 / July / 21 / 5
charlie5
mm, no light bulbs going off here :/
Visaoni
well, if nothing else the reminder that I can, in fact, give up is a useful one
charlie5
i think i'd make the generator type tagged and be damned :)
Visaoni
I'll think about that a little more and see how many of these problems it would solve
I haven't really messed with interfaces and stuff at all, so I probably need to experiment a bit with them and see how things work out
charlie5
yeah, tbh, i've really not thought it completely thru (and may well be talking crud)
Visaoni
oh I think you're totally right on this, I just haven't told you everything :)
charlie5
heh, you will have to put full code online somewhere ... the i will have no excuse :)
the -> then
but for 2n8, good luck ... for me, it's bed ;)
Visaoni
should have been awhile ago for me too :)
charlie5
heh, we should both be sleeping on it then
n8 :)
Visaoni
night
darkestkhan
Visaoni: if someone wants performance with tagged type (and operations on it) then he should not dispatch...
nerdboy
moin
sukaeto
Visaoni: if you're only opposed to tags because of dynamic dispatch
Visaoni: you could declare an interface type with all the operations you need your Generator to support
Visaoni: and then you could do something along the lines of:
generic
type Generator is new The_Interface with private;
type Result_Type is (<>);
function Random(Gen : Generator) return Result_Type;
there will be no dispatching, becuase whatever you pass in for Generator will be a (concrete? ground?) type (i.e. it will not be a class-wide type)
The_Interface can have as many operations as you want, it won't clog up the definition of the generic (and worse, force the user to pass in all the subprograms upon instantiation!)
jk4
interfaces are usually a better method
subtyping has some icky traits
tkoskine
Lucretia: I don't know much about gpr* tools. (Slow response, just came back from ~5 day holiday trip.)
Lucretia
k
can't remember what the question was now
tkoskine
"16:44 < Lucretia> seems gprinstall doesn't copy over my version.gpr..."
Lucretia
ah yeah
didn't find out, just used install to do it
but definitely seems like they never thought about it
Shark8
!last
dmbaturin
http://www.functor.se/research/paradigm/ Apparently, the day when formal verification becomes a buzzword has come.
Shark8
dmbaturin: Well sh*t. :(
jk4
it's okay. no one will do it right anways
Shark8
This means we're going to have some flimsy toilet-paper thin veneer of formal verification come out which will, obviously, be difficult and/or of greatly reduced utility.
dmbaturin
Well, maybe it can spark (no pun intended) some interest in actual formal verification techniques.
jk4
they're still wrong.. c++ is 25 years old and hasn't really done much to make software better, but has added syntactical sugar mostly afaict
templates are still horrendous
macros
Shark8
(Action) imagines a "dependent-type system" based heavily on the preprocessor /and/ templates.
(Action) shudders
dmbaturin
They promise dependent types with zero learning curve somehow.
darkestkhan
so how does dependent type differ from what Ada already offers?
Shark8
I /think/ there's ways to make things like an "Open_File" and "Closed_File" as types... of course that's a really vague notion that I'm only like 20% sure about.
But, yeag, it seems like Ada's already got most of what you'd really want it for. -- https://en.wikipedia.org/wiki/Dependent_types
*yeah
darkestkhan
Shark8: this is why I'm asking ... what is the point of it? and how it would be used?
dmbaturin
darkestkhan: Well, there is no direct support for inductive types and recursive definitions in Ada, for instance.
jk4
the pre/post conditions can sort of emulate it.. sort of
erm
predicates
darkestkhan
dmbaturin: we got pre/post and predicates
much can be done with them...
and then there are aspect clauses (just look at Dimension aspects from gnat)
Shark8
Given the "languages that use dependent types" section it looks like they're used in theorem-provers; I'm not entirely sure about "the point" other than what we can get by Ada's [sub]types where we can, say, produce a string-type which only has valid identifiers as possible values.
jk4
this syntax is icky though
Shark8
!last
jk4: Which syntax?
jk4
predicates
this with Baloney => Whatever
dmbaturin
darkestkhan: Sure. Coq or Agda are by no means general-purpose languages, they don't even allow non-terminating functions, for instance.
jk4
dmbaturin: minor detail
darkestkhan
Shark8: type File_Type is tagged ...; type Open_File is new File_Type with Type_Invariant (Is_Open (File_Type)); -- something like this for Open_File type.. dunno if it works and how well
jk4: yeah, forgot that => after Type_Invariant
jk4
despite ada being verbose
i think that syntax is pretty wordy
without any benefit
Shark8
darkestkhan: I see.
darkestkhan
Shark8: but there is one problem
Shark8
jk4: It seems pretty terse to me... what would you do to make that sort of functionality if you were given free-reign?
darkestkhan: Which is?
darkestkhan
if I define File_Closed and File_Open in different packages then we get into mutual dependency issue
(cause, presumably, you want Close to return File_Closed, and Open to return File_Open)
jk4
Shark8: i haven't applied any thought to it
darkestkhan
[open defined for File_Closed, close defined for File_Open]
Shark8
Hm, true... but then again I don't think they should be in different packages.
jk4
but i don't think i'm positioned to provide an alternative
darkestkhan
agreed
jk4: dunno, lately I'm thinking about Object_Predicates
jk4
nothing magical about the file stuff that's being discussed
darkestkhan
you may want certain objects to have certain properties, particularly when you do some marshalling
[playing around with 'Address can give you interesting results]
Shark8
Though if I were doing it I'd probably put the File_Open and File_Closed types (w/ appropriate predicates) within a single generic package which would have, as the formal parameter the base/parent File_Type type and the appropriate functions.
darkestkhan: This is true; I have a few data-parsers which I made so that the actual-parsing is the same whether it's from a string or a stream.
It's kinda ugly, but having a unified parse-function is very desirable.
darkestkhan
Shark8: I quite often just marshall various arrays, but I would like to have some way to ensure that their sizes are correct
I suppose one could use pragma Assert
Shark8
darkestkhan: The 'Input and 'Output attributes *should* take care of ensuring proper bounds.
darkestkhan
Shark8: yeah, sure... but I don't care about bounds... I have array of floats, there is function Ada.Strings.Fixed.Hash - why not use this hash for Hashed_Set for example?
Shark8
?? But if the bounds are set, then you have the length as well.
I don't know about the Strings.Fixed.Hash and Hashed_Set... I don't think I've used either.
darkestkhan
Shark8: I did ;)
why write hash of your own if you got one from stdlib?
[at least for use in hash tables etc.]
I used Set only once so far - because I was specifically interested in having unique elements
and Hashed at that because in this case, usually, I do a lot more searching than inserting
« prev 1 2 3 4 5 6 next »